使用实体框架4的域驱动设计

Question

我读过一些讨论如何将EF实体用作业务对象的帖子

Using Entity Framework entities as business objects?

但是，这不是使业务对象的设计依赖于数据模型吗？这是企业应用程序的正确实践吗？域和数据模型不应该是独立的，其中一个模型的更改不应该影响另一个模型吗？如果我选择将它们分开，那么我是否需要创建另一个层来填充来自EF实体的业务对象？如果我同时有自定义业务对象和EF实体，那么哪一个用于在层之间传输数据(包括所有到UI的方式)？有没有这样的架构模式？如果有一个示例应用程序来演示这些概念(而不是简单的演示版本，适合在企业应用程序中使用)，这将非常有用。

这个链接清楚地解释了这个问题

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx#id0420099

Answer 1

这取决于您希望/需要的松散耦合程度。

以WPF/MVVM应用为例，它通过WCF与服务通信，并使用EF存储数据。然后，如果你一直这样做，你会得到以下结果：

在客户端：

• View
• ViewModel
• Model

在客户端和服务器之间：

• Data transfer object

在服务器上：

• Entities
• EF Entities

在每一层之间具有映射代码。这可能是大量的工作和对象之间的重复。它可能不太实用，因为有这么多层。我们尝试在可能的情况下将它们结合起来，例如DTO也可以作为模型吗？

使用部分类，您可以向EF类添加功能，如果重新生成模型，这些功能将不会被删除。因此您可以将其用作您的业务实体。

出于以下原因，我不会将它们用作DTO：

• 数据库中的更改可能会影响许多系统
• 非MS客户端可能正在使用您的服务

Answer 2

这是一个有争议的问题，它完全取决于你想要在多大程度上构建你的应用程序……

有强烈的意见主张使用DTO/POCO (Plain Old CLR Obects)，实际上是你的can use EF to generate DTO's to achieve such a thing。这是一种关于架构的the Rolls-Royce ...关键的优点是，您可以将业务逻辑与数据访问分离，然后在理论上使您能够在未来切换到最新和最好的ORM。缺点是(正如您在问题中所说的)，您需要一个映射服务来在两个层之间进行转换，并且您实际上最终会使用多个类来表示相同的数据。

通常，DTO/POCO的使用对于小型/中型不被提倡，因为增加了代码膨胀，然而，对于较大的项目，尽管增加了大量编码，但关注点的分离可能是有益的。无论是不是企业级应用程序，我认为您都需要考虑这样一个现实:您是否想要换掉ORM工具(即EF)。

此外，我认为EF生成的类已经足够简单，并将大部分数据访问代码隐藏在".designer.cs“中，甚至大部分代码都具有声明性属性。

因此，我的个人观点，虽然可能是有争议的，是同意the accepted answer in the linked post，并使用实体框架实体作为业务对象。我也同意这是EF (和大多数ORM)背后的意图。

请仔细查看this series of articles以了解更多信息。