我应该如何处理使用的IoC /依赖注入我的实体/域对象？ [英] How should I handle my Entity/Domain Objects using IoC/Dependency Injection?

问题描述

我目前使用PLINQO生成从数据库中我所有的实体。

I'm currently using PLINQO to generate all my Entities from the database.

最近，我开始使用StructureMap使用依赖注入，而随着部分分离我的顾虑的学习过程。我注意到，所有生成的实体类包含了使用的EntitySet，LINQ的一部分，这使我的实体依赖于使用System.Data.Linq程序高度耦合的属性。

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.

我想继续使用我的PLINQO生成的实体，但在同一时间，我觉得我也许应该产生某种基类/只的数据对象，甚至在将它们移动到不同的组装，然后使用某种自动映射器的两个之间进行转换，根据需要。在最好的（或最坏，取决于你如何看待它），我想一些接口来表示这些，这样我可以用不同的具体类型后注入它们。

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.

这是矫枉过正？最后，我将远离直接使用SQL Server来使用Web服务活动，我怀疑那些EntitySets会通过电线，很容易。

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

推荐答案

我认为你是正确的轨道上 - 不要让生成的L2S类的名字骗了。它们不是在DDD术语实体，但是数据库的简单强类型的表示。如果你问我，这是不应该被允许侵入领域层的实现细节。

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.

通过确认当期的.NET架构，如果你用纯粹停留BCL和使用没有额外的库，你唯一的选择就是在你的域模型来定义持久无知实体，然后这些映射到L2S类数据访问层英寸这是一个痛苦，但 AutoMapper 可以在这方面有所帮助。

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.

如果你愿意偏离纯BCL有点有开放源码库，提供持续性的无知，如的 NHibernate的 - 我没有与NHibernate的任何个人的经验，但很多聪明人看得起它

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.

在.NET 4.0，实体框架，从而LINQ到实体的也将提供持久性的无知

In .NET 4.0, the Entity Framework, and thereby LINQ to Entities will also offer persistence ignorance.

杰里米米勒拥有的文章MSDN杂志认为，有些触及的主题。

这篇关于我应该如何处理使用的IoC /依赖注入我的实体/域对象？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！