分层体系结构中的实体框架

Question

最近我读过文章" 分层架构中的实体框架 ",并写了我们可以通过WCF向客户端发送EF实体.但是在Stackoverflow上的许多线程中,人们告诉我们在使用WCF时应该使用POCO(DTO)对象.我有一些问题.

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

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

3. 如果我已经拥有自己的业务实体,它有一些方法,并且它应该映射到POCO对象,我应该在哪个层上将POCO-object转换为我的实体(例如,我有持久层,业务逻辑层,服务层(WCF),演示者层(客户端,使用WCF),UI层)？或者我不应该做我自己的实体？

提前致谢

Answer 1

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

一般来说，在服务层中公开 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。您将在应用程序的服务器层（持久层、业务层、服务层和表示层）中透明地使用域模型，唯一需要 DTO 映射的层是服务层，请参阅问题 1。（此外，如果您在演示者层中使用 ViewModel - 好主意 - 您也需要在演示者层中使用 POCO 映射）。