我应该如何使用 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 服务，而且我怀疑那些 EntitySet 会那么容易通过网络.

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 to Entities 也将提供持久性无知.

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

Jeremy Miller 在 MSDN 杂志上发表了一篇文章，稍微触及了这个主题.

Jeremy Miller has an article in MSDN Magazine that somewhat touches upon the subject.

这篇关于我应该如何使用 IoC/Dependency Injection 处理我的实体/域对象?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持html5模板网！