POCO與實體框架生成的類？

Question

使用其中一種的優點是什麼？我知道POCO課程更優化，但它們值得過度殺傷？我們是否應該一直使用POCO？或者是否有一段時間您應該更喜歡實體框架類？

Answer 1

EF默認類都從EF基類繼承，而POCO不（因此名稱）。從EF基類繼承而來，變更追蹤背後的邏輯對你來說是隱藏的，所有的邏輯都存儲在持有對象引用的上下文中。如果你在連接狀態下工作，那麼這是首選，也就是說，你在有實體的同時有上下文。這通常是您建立「胖」客戶端的情況，所以客戶端和數據庫是唯一的兩個層。另一方面，如果您使用的是Web服務/ Web表單，那麼您傳遞的實體沒有上下文並且必須自己跟蹤狀態 - 那麼POCO是更好的選擇，因爲它們將跟蹤對象的屬性更改爲可以轉移的屬性，直到您決定將更改應用於上下文並保存爲止。另一個好處是你的客戶不必是.NET，也不需要EF.DLL反序列化你的對象。

Answer 2

我使用POCO的原因是關注點的分離，即我不希望我的前端必須知道我的後端是如何工作的。所以如果我想從Linq To Sql更改爲EF或N休眠，我不必修改我的前端代碼。

Answer 3

如果您需要乾淨的架構，鬆耦合和最高的可測性，請使用POCO。

如果你不關心這些東西，那就不要使用它們。

對我個人而言，這些是任何應用程序中最重要的事情（尤其是需要長時間維護的應用程序），因此我總是使用POCO。

有鑑於此，POCO要求您實施某種更改跟蹤機制，這可能會非常棘手。但這是一次性設置，值得努力。

我在一個自定義的DLL中有這個邏輯，我在項目之間共享 - 所以我不必一直這樣做。

有關POCO爲什麼在一般意義上很重要的更多信息（而不是EF/.NET特定），請參閱我的回答here。

Answer 4

請看下面的文章：

http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

http://blogs.msdn.com/b/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferred-loading-and-explicit-loading.aspx

http://blogs.msdn.com/b/adonet/archive/2009/06/10/poco-in-the-entity-framework-part-3-change-tracking-with-poco.aspx