我应该将EF中的实体看作域模型还是DTO？

我是实体框架的新手（代码优先，如果重要）。正如我一直在使用它，我一直在构建我的POCO课程，并将它们视为最终的领域模型。通过Lazy Loading之类的东西，我喜欢Idea，我可以直接在我的表示层中使用这些实体，从而延迟加载实际需要的内容。我应该将EF中的实体看作域模型还是DTO？

但是，我最近也了解到数据传输对象，这是我以前从未听说过的。这绝对有道理;我的最终域模型的行为可能有一些不属于DAL的业务规则。例如，如果我给实体框架的POCO SalesOrder包含最终方法，如AddItem(Product)，如果Product的DiscontinuedDate位于SalesOrder.OrderDate之前，则会引发异常。这听起来像是属于BLL的东西。

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

我在这里的正确轨道，或者我错过了什么。我感到困惑是因为DTO的想法非常合理，但我从未在实体框架中看到过它们的使用。

来源

2013-09-25 JHixson

我有一个类似的问题，回来，并得到了一些可能对你有用的答案：http://stackoverflow.com/questions/11521192/placement-of-dto-poco-in-a-three-二线项目 – GrandMasterFlush

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

他们

简单的小数据持有人只是属性和方法没有

肯定。

来源

2013-09-25 13:24:03

这取决于你。只有属性被映射，所以你可以自由地添加方法（并与数据库第一部分类生成，所以你可以做同样的）。

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

但是请注意，业务逻辑不应该驻留在实体中。尽管只需粘贴Customer.FullName属性（它返回Customer.FirstName + " " + Customer.LastName）可能很诱人，但您需要在相应的类中使用类似这样的逻辑（就像RegisterCustomer()方法一样）。

来源

2013-09-25 13:23:00 CodeCaster

在一些简单的情况下，实体可能是DTO，查看模型和域模型（在非常简单的情况下 - 同时）。

但是，一般情况下，最好保留单独的DTO，单独的视图模型和单独的域模型。例如，对于表示层或DTO，有很多具体的东西可能是必需的，但不需要在实体类中实现它们。

来源

2013-09-25 13:25:02 Dennis

我应该将EF中的实体看作域模型还是DTO？

回答

相关问题