我應該將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？

回答

相關問題