我已经阅读了一些讨论如何将 EF 实体用作业务对象的帖子
Using Entity Framework entities as business objects?
但这不会使业务对象的设计依赖于数据模型吗？这是企业应用程序的正确做法吗？域和数据模型不应该是独立的，并且其中一个的更改不应该影响另一个吗？如果我选择将它们分开，那么我是否需要创建另一个层来填充来自 EF 实体的业务对象？如果我同时拥有自定义业务对象和 EF 实体，哪一个用于在层之间传输数据（包括一直到 UI）？有这样的架构模式吗？如果有演示这些概念的示例应用程序（不仅仅是演示版本，适合在企业应用程序中使用），那将很有用。
此链接清楚地解释了问题
http://msdn.microsoft.com/en-us/magazine/dd882510.aspx#id0420099
【问题讨论】：
标签： .net entity-framework design-patterns architecture entity-framework-4
这取决于您想要/需要的松散耦合程度。
以一个 WPF/MVVM 应用为例，它通过 WCF 与服务通信并使用 EF 存储数据。那么如果你一路走下去，你就有了以下：
在客户端：
客户端和服务器之间：
在服务器上：
每层之间带有映射代码。这可能是对象之间的大量工作和重复。有这么多层可能不实用。我们尽可能将它们结合起来，例如 DTO 也可以作为模型吗？
使用部分类，您可以向 EF 类添加功能，这些功能在重新生成模型时不会被删除。因此，您可以将 then 用作您的业务实体。
出于以下原因，我不会将它们用作 DTO：
【讨论】：
这是一个有争议的问题，它完全取决于您想要构建应用程序的程度...
有强烈的意见主张使用 DTO/POCO（普通旧 CLR 对象），实际上你 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 了解更多信息。
【讨论】：