使用实体框架 4 的领域驱动设计
我读过一些讨论如何使用 EF 实体作为业务对象的帖子
但这是否会使业务对象的设计依赖于数据模型？这对于企业应用程序来说是正确的做法吗？域和数据模型不应该是独立的，并且其中一个模型的更改不应影响另一个模型吗？如果我选择将它们分开，那么我是否需要创建另一个层来填充 EF 实体中的业务对象？如果我同时拥有自定义业务对象和 EF 实体，那么哪一个用于在层之间传输数据（包括一直到 UI）？有这样的架构模式吗？如果有一个演示这些概念的示例应用程序（不仅仅是演示版本，适合在企业应用程序中使用），那将会很有用。
此链接清楚地解释了问题
I have read some posts which discuss about how to use EF entities as business objects
Using Entity Framework entities as business objects?
but doesn't this make the design of the business objects dependent on the data model? Is this the right practice for enterprise applications? shouldn't the domain and data model be independent and changes in one shouldn't affect the other? if I choose to keep them separate, then do I need to create another layer to populate the business objects from the EF entities? if I have both custom business objects and the EF entities, which one is used to transfer data between layers (including all the way to UI)? is there an architectural pattern for this? It would be useful if there is a sample application that demonstrates these concepts (not simply a demo version, suitable to use in an enterprise application).
This link explains the problem clearly
http://msdn.microsoft.com/en-us/magazine/dd882510.aspx#id0420099
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于您想要/需要的松散耦合程度。
以通过 WCF 与服务通信并使用 EF 存储数据的 WPF/MVVM 应用程序为例。然后，如果您一路走下去，您将拥有以下内容：
在客户端上：
在客户端和服务器之间：
在服务器上：
在每层之间具有映射代码。这可能需要大量工作以及对象之间的重复。有这么多层可能不太实用。我们尝试尽可能地将它们结合起来，例如DTO也可以作为模型吗？
使用分部类，您可以向 EF 类添加功能，这些功能在重新生成模型时不会被删除。所以您可以将其用作您的业务实体。
我不会将它们用作 DTO，原因如下：
It depends on how loosly coupled you want / need to be.
Take for example a WPF/MVVM app that talks to a Service via WCF and stores data using EF. Then if you go all the way you have the following:
On the client:
Between client and Server:
On the server:
With mapping code between each layer. This can be a lot of work and duplication between objects. It may not be practical too have so many layers. We try to combine them where possible, for example can the DTO also be the model?
Using partial classes you can add functionality to EF classes that will not be deleted if the model is regenerated. So you could use then as your business entities.
I would not use them as DTO's for the following reasons:
这是一个有争议的问题，它完全取决于您想要构建应用程序的程度...
有强烈的观点主张使用 DTO/POCO（普通旧 CLR 对象），而您确实可以使用EF生成DTO来实现这样的事情。在建筑方面，这是一种劳斯莱斯......主要优点是您可以将业务逻辑与数据访问分离，然后理论上使您能够在未来切换到最新、最好的 ORM。缺点是（正如您在问题中所说）您需要一个映射服务来在两个层之间进行转换，而且您实际上最终会得到多个类来表示同一条数据。
一般来说，不提倡在小型/中型项目中使用 DTO/POCO，因为会增加代码膨胀，但是，对于较大的项目，尽管增加了编码量，但关注点分离可能是有益的。无论是否是企业应用程序，我认为您需要考虑是否要更换 ORM 工具（即 EF）的现实。
此外，我认为 EF 生成的类已经足够简单，并且隐藏了“.designer.cs”中的大部分数据访问代码，甚至其中的大部分都带有声明性属性。
因此，我个人的观点（尽管可能是有争议的）是同意 链接帖子中接受的答案并使用实体框架实体作为业务对象。我也同意这首先是 EF（以及大多数 ORM）背后的意图...
仔细阅读 此 系列文章了解更多信息。
This one is a contentious one and it totally depends on how far you want to architect your app...
There are strong opinions that advocate using DTO/POCO (Plain Old CLR Obects) and indeed you can use EF to generate DTO's to achieve such a thing. This is kind of the Rolls-Royce with regard to architecture... The key advantage is that you decouple your business logic from your data access and then in theory enable you to switch to the latest and greatest ORM in the future. The disadvantage being that (as you said in your question) you need a mapping service to translate between the two layers as well as the fact that you're essentially ending up with multiple classes to represent the same piece of data.
Generally, the use of DTO/POCO is not advocated for small/medium because of the added code bloat, however, for larger projects the separations of concerns can be beneficial despite the added volumes coding. Enterprise application or not, I think you need to consider the reality of whether or not you'd ever want to switch out your ORM tool (that is, EF).
Additionally, I think the EF generated classes are sufficiently simple enough already and hide the majority of data access code in the ".designer.cs" and even then the bulk of it with declarative attributes.
So my personal opinion, albeit probably a controversial one, is to agree with the accepted answer in the linked post and use the entity framework entities as business objects. I would also agree that this is the intent behind EF (and most ORM's) in the first place...
Have a good look through this series of articles for more information.