我已经阅读了一些讨论如何使用 EF 实体作为业务对象的帖子
Using Entity Framework entities as business objects?
但这不是使业务对象的设计依赖于数据模型吗？这是企业应用程序的正确做法吗？域和数据模型不应该是独立的，一个的变化不应该影响另一个吗？如果我选择将它们分开，那么我是否需要创建另一个层来填充来自 EF 实体的业务对象？如果我同时拥有自定义业务对象和 EF 实体，哪一个用于在层之间传输数据(包括一直到 UI)？有没有这方面的架构模式？如果有演示这些概念的示例应用程序(不仅仅是演示版本，适合在企业应用程序中使用)，那将会很有用。
此链接清楚地说明了问题
http://msdn.microsoft.com/en-us/magazine/dd882510.aspx#id0420099
最佳答案
这取决于您想要/需要的松散耦合程度。
以一个 WPF/MVVM 应用程序为例，它通过 WCF 与服务对话并使用 EF 存储数据。然后，如果你一路走下去，你会得到以下内容:
在客户端:
客户端和服务器之间:
在服务器上:
每层之间带有映射代码。这可能是大量的工作和对象之间的重复。有这么多层可能不太实用。我们尽量将它们结合起来，例如 DTO 也可以作为模型吗？
使用分部类，您可以向 EF 类添加功能，如果重新生成模型，这些功能将不会被删除。因此，您可以将 then 用作您的业务实体。
由于以下原因，我不会将它们用作 DTO:
关于.net - 使用 Entity Framework 4 的领域驱动设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7839549/