c# - 分层架构中的 Entity Framework

Question

最近我读了文章“The Entity Framework In Layered Architecture”，其中写道我们可以通过 WCF 将 EF 实体发送给客户端。但是在 Stackoverflow 上的许多线程中，人们告诉我们在使用 WCF 时应该使用 POCO(DTO)-objects。我有一些问题。

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

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

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

提前致谢

Answer 1

1.Why did Microsoft add DataContract attribute to EF-entities? Does Microsoft wanted us to use these objects everywhere in our applications? Or this is only for very simple applications and for rapid development?

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

2.If I use POCO-objects, should I create auto generated EF-Entities, POCO-Entities and after that use any mapping library between them? Or I should use only POCO-objects in all components of my application?

您可以在服务层内使用 POCO 对象，将其与任何底层分离(请参阅 Automapper，以支付 Entity-DTO 映射成本)。但您仍然可以在架构的数据层和业务层之间使用自动生成的 EF 实体。只是尽量不要依赖与数据层不同的其他层中生成的域模型的 EF 特定功能。以简化向另一个 ORM 框架的迁移。

If I already have my own business entity, which has some methods, and it should be mapped to POCO object, on which layer should I convert POCO-object to my entity (for example, I have persistence layer, business logic layer, service layer(WCF), presenter layer (client, use WCF), UI layer)? Or I shouldn't make such my own entities?

服务层http://msdn.microsoft.com/en-us/library/ms978717.aspx .您将在应用程序的服务器层(持久层、业务层、服务层和展示层)之间透明地使用域模型，并且唯一需要 DTO 映射的层是服务层，请参见问题 1。(此外，如果您在您的演示层中使用 ViewModels - 好主意 - 您也需要在演示层中使用 POCOs 映射)。