问题描述
我正在使用PLINQO从数据库中生成所有的实体。
最近，我已经开始使用StructureMap使用依赖注入，并且作为分离我的忧虑的学习过程。我注意到，所有生成的实体类都包含使用EntitySet（LINQ的一部分）的高度耦合的属性，这使得我的实体依赖于使用System.Data.Linq。
我想继续使用我的PLINQO生成的实体，但同时，我觉得我应该可能会生成一些基类/数据的对象，甚至可能将它们移动到不同的程序集中，然后使用某种自动映射器根据需要在两者之间进行转换。最好的（最糟糕的是，根据你的看法），我想要一些界面来表示这些，所以我可以在后面注入不同的具体类型。
有没有人有一些使用这种情况的好例子？
TIA
我认为你在正确的轨道上 - 不要让生成的L2S类的名字愚弄你。它们不是DDD术语中的实体，而是数据库的强类型表示。如果你问我，那就是一个不应该被允许侵入域层的实现细节。
使用currect的.NET框架，如果你保持纯粹的BCL并且不使用额外的库，您唯一的选择是在域模型中定义持久性无知实体，然后将它们映射到数据访问层中的L2S类。这是一个痛苦，但可以在这方面有所帮助。
如果您愿意偏离纯BCL，那么提供持久性无知的开源库，例如 - 我没有NHibernate的任何个人经验，但很多聪明的人都很高兴。
在.NET 4.0，实体框架，从而LINQ to Entities 。
Jeremy Miller有一个。
I'm currently using PLINQO to generate all my Entities from the database.
Recently, I've started to use dependency injection using StructureMap, and as part of the learning process of "separating my concerns". I've noticed that all the generated Entity classes contain highly-coupled properties using EntitySet, part of LINQ, which make my entities dependent on using System.Data.Linq.
I would like to continue to use my PLINQO generated entities, but at the same time, I feel like I should probably generate some sort of base-classes/data-only objects, and perhaps even move them in to a different assembly, then use some sort of auto mapper to convert between the two, as needed. At best (or worst, depending how you look at it), I'd like some interfaces to represent these, so that I can inject them with different concrete types later.
Is this overkill? Eventually, I'll be moving away from using SQL Server directly to using Web Services, and I doubt those EntitySets will go over the wire that easily.
Does anyone have some good examples of working with a scenario like this?
TIA
I think you are on the right track - don't let the name of the generated L2S classes fool you. They are not Entities in the DDD terminology, but simply strongly typed representations of the database. If you ask me, that is an implementation detail that should not be allowed to invade the Domain Layer.
With the currect .NET framework, and if you stay purely with the BCL and use no extra libraries, your only option is to define persistent-ignorant Entities in your Domain Model and then map those to the L2S classes in the data access layer. It's a pain, but AutoMapper can be helpful in that regard.
If you are willing to deviate a bit from the pure BCL there are open-source libraries that offer persistence ignorance, such as NHibernate - I don't have any personal experience with NHibernate, but lots of smart people think highly of it.
In .NET 4.0, the Entity Framework, and thereby LINQ to Entities will also offer persistence ignorance.
Jeremy Miller has an article in MSDN Magazine that somewhat touches upon the subject.
这篇关于如何使用IoC /依赖注入处理我的实体/域对象？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！