分层架构中的实体框架

最近我读了一篇文章“分层架构中的实体框架 http://msdn.microsoft.com/en-us/magazine/cc700340.aspx”并且写道我们可以通过 WCF 将 EF 实体发送到客户端。但是在 Stackoverflow 上的许多线程中，人们告诉我们在使用 WCF 时应该使用 POCO(DTO) 对象。 我有一些问题。

1. 为什么 Microsoft 向 EF 实体添加 DataContract 属性？ Microsoft 是否希望我们在应用程序中的任何地方都使用这些对象？或者这仅适用于非常简单的应用程序和快速开发？

2. 如果我使用 POCO 对象，我是否应该创建自动生成的 EF 实体、POCO 实体，然后在它们之间使用任何映射库？或者我应该在应用程序的所有组件中仅使用 POCO 对象？

3. 如果我已经有了自己的业务实体，它有一些方法，并且应该映射到 POCO 对象，我应该在哪一层将 POCO 对象转换为我的实体（例如，我有持久层、业务逻辑层、服务层） （WCF），表示层（客户端，使用WCF），UI层）？或者我不应该创建这样的我自己的实体？

提前致谢

1.微软为什么要添加DataContract 归因于 EF 实体？做 微软希望我们使用这些 我们身边随处可见的物体 应用程序？或者这仅适用于非常 简单的应用程序和快速 发展？

一般来说，在服务层中公开 EF 实体是一个坏主意，因为这很难耦合服务层和模型表示。因此，模型中所做的任何更改都会直接影响您的服务，这不是一个好主意。此外，您有时还必须对服务层进行版本控制，因此请避免公开服务层中的 EF 实体。

2.如果我使用 POCO 对象，我应该创建自动生成的 EF 实体吗？ POCO-实体，然后使用任何 它们之间的映射库？或者我 应该只使用 POCO 对象 我的应用程序的组件？

您可以在服务层内使用 POCO 对象，将其与任何底层分离（请参阅 Automapper，以覆盖 Entity-DTO 映射成本）。但您仍然可以在架构中的数据层和业务层中使用自动生成的 EF 实体。只是尝试不依赖于与数据层不同的其他层中生成的域模型的 EF 特定功能。轻松迁移到另一个 ORM 框架。

如果我已经有了自己的事业 实体，它有一些方法，并且它 应该映射到 POCO 对象，在 我应该转换哪一层 POCO-我的实体的对象（例如， 我有持久层，业务 逻辑层、服务层(WCF)、 演示者层（客户端，使用WCF），UI 层）？或者我不应该这样 自己的实体？

服务层http://msdn.microsoft.com/en-us/library/ms978717.aspx http://msdn.microsoft.com/en-us/library/ms978717.aspx。您将在应用程序的服务器层（持久层、业务层、服务层和表示层）中透明地使用域模型，唯一需要 DTO 映射的层是服务层，请参阅问题 1。（此外，如果您在演示者层中使用 ViewModel - 好主意 - 您也需要在演示者层中使用 POCO 映射）。