2

我是实体框架的新手（代码优先，如果重要的话）。当我一直在使用它时，我一直在构建我的 POCO 类，将它们视为最终的域模型。对于延迟加载之类的东西，我喜欢这样的想法，即我可以直接在我的表示层中使用这些实体，从而延迟加载我真正需要的东西。

但是，我最近还了解了数据传输对象，这是我以前从未听说过的。这绝对有道理；我的最终域模型的行为可能有一些不属于 DAL 的业务规则。例如，如果SalesOrder我提供给实体框架的 POCO 是否包含它的最终方法，例如，AddItem(Product)如果在. 这听起来绝对像是属于 BLL 的东西。ProductDiscontinuedDateSalesOrder.OrderDate

所以，我想这意味着我给实体框架的 POCO 类应该更像 DTO 的？，就像SalesOrderDto只是EmployeeDto简单的小数据持有者，只有属性，没有方法，然后被映射（可能使用 AutoMapper）到我的 BLL 中的域对象，然后传递给表示层？

我是在正确的轨道上，还是我错过了什么。我感到困惑，因为 DTO 的想法非常有意义，但我从未见过它们在实体框架的上下文中使用。

4

3 回答 3

1

由你决定。仅映射属性，因此您可以自由添加方法（并且使用 Database First 生成部分类，因此您可以执行相同操作）。

通常，业务对象不一定直接映射到存储对象。在这种情况下，您的业务对象可以存在于一个或多个存储对象之外，是否将这些（自动）映射到 DTO 的第一个也取决于您。

但是请注意，业务逻辑无论如何都不应该驻留在实体中。虽然只保留Customer.FullName属性（返回）可能很诱人，但您会希望在适当的类中使用Customer.FirstName + " " + Customer.LastName这样的逻辑（就像方法一样）。RegisterCustomer()

于 2013-09-25T13:23:00.477 回答
1

在一些简单的情况下，实体可能是 DTO、视图模型和域模型（在非常简单的情况下——同时）。

但是，一般来说，最好保留单独的 DTO、单独的视图模型和单独的域模型。有许多特定的东西可能是必需的，例如表示层或 DTO，但您不需要在实体类中实现它们。

于 2013-09-25T13:25:02.940 回答
0

实体框架是一个对象关系映射器。因此，实体是到您的关系表的映射。

他们是

简单的小数据持有者，只有属性，没有方法

是的。

于 2013-09-25T13:24:03.323 回答