我是Entity Framework的新手（代码优先，如果重要的话）。正如我一直在使用它，我一直在构建我的POCO类，将它们视为最终域模型。对于像Lazy Loading这样的东西，我喜欢我可以在我的表示层直接使用这些实体的想法，懒得加载我真正需要的东西。
但是，我最近也了解了数据传输对象，这是我以前没有听说过的。这绝对有道理;我的最终域模型的行为可能有一些不属于DAL的业务规则。例如，我向实体框架提供的POCO SalesOrder是否应包含AddItem(Product)等最终方法，如果Product的{{1}}位于DiscontinuedDate之前，则会引发异常{1}}。这听起来好像属于BLL的东西。
所以，我想这意味着我给实体框架的POCO类应该更像DTO的？，如SalesOrder.OrderDate和SalesOrderDto只是简单的小数据持有者，只有属性，没有方法然后获取映射（可能使用AutoMapper）到我的BLL中的域对象，然后传递给表示层？
我在这里是正确的轨道，还是我错过了什么。我感到困惑，因为DTO的想法很有道理，但我从未见过它们在实体框架的背景下使用过。
答案 0 :(得分：1)
这取决于你。只映射了属性，因此您可以自由添加方法（并且可以生成Database First部分类，因此您也可以这样做。）
通常，业务对象不一定直接映射到存储对象。在这种情况下，您的业务对象可以存在于一个或多个存储对象之外，无论是否（自动）将这些对象映射到DTO也是由您决定。
但请注意，业务逻辑不应该驻留在实体中。虽然只是坚持Customer.FullName属性（返回Customer.FirstName + " " + Customer.LastName）可能很诱人，但您需要在适当的类中使用这样的逻辑（就像RegisterCustomer()方法一样）。
答案 1 :(得分：1)
在一些简单的情况下，实体可能是DTO，视图模型和域模型（在非常简单的情况下 - 同时）。
但是，一般来说，最好保留单独的DTO，单独的视图模型和单独的域模型。有许多特定的东西，例如，对于表示层或DTO，可能是必需的，但您不需要在实体类中实现它们。
答案 2 :(得分：0)
Entity Framework是一个Object Relatonal Mapper。因此，实体是映射关系表的映射。
他们是
简单的小数据持有者只有属性而没有方法
是