將實體框架（POCOs）對象中的業務對象分離的必要性？

Question

在我們的應用程序中，我們將現有的DAL從EF 4.0升級到EF 5.0。
目前一個通用的存儲庫模式已經實現，我們使用POCO對象作爲商業實體。
這些對象使用WCF屬性進行裝飾，因爲它們通過Web服務接口傳遞，並使用部分類進行擴展，以便添加更多業務和驗證方法。此外，每個POCO實體都從基類「BusinessEntity」和接口「IBusinessEntity」繼承，以便輕鬆使用泛型庫方法。

我們正計劃將業務實體與POCO對象分離開來，以使後者成爲僅具有屬性且無邏輯的普通類。

然而，在閱讀了這個話題之後，似乎當前的技術狀態是採用代碼優先的方法並直接堅持域實體（即使當然不可能對所有情況進行概括）。
Related answer 1，related answer 2。

在我們的案例中，將POCO對象與業務邏輯保持在一起並僅應用與EF 5.0（DbContext）相關的更改是否合理？或者說，我們應該在資源庫中引入一個映射層？通過這種方式，應用程序可以在業務實體上工作，並且存儲庫層將從外部隱藏POCO對象。但缺點是複雜性的引入，特別是在處理通用存儲庫時。

在此先感謝。

Answer 1

我想與你分享我的經驗，關於你的問題，雖然我來到這裏找到解決其他相關問題的方法。

我讀過的大多數人和文章都說要使用EF POCO作爲業務對象......對我來說，看起來像EF推動了這種趨勢，因爲如果你想解耦它們，它可能會使開發變得更加複雜。

你說你已經在系統中使用了POCO。那麼，我希望你從相反的角度來看待它：我們有一個項目，開始時，DAL使用我們自己的基本「數據庫處理程序」（使用純ADO.NET編寫）和我們自己的業務類;但現在我們也試圖支持實體框架，另外（所以我們加載舊的數據庫處理程序或EF ...也許以後我們將切換到EF）。由於我們希望保持數據庫的原樣，我們採用數據庫優先的方法;現在我們找不到一種方法來使我們現有的業務對象與POCO之間的連接更容易（我們現在使用簡單的「投影」進行轉換）。其中有一個List<BObject2>

所以，在BL，以下preudo代碼插入一個BObject1（1：N的關係）是這樣的：

this.UnitOfWork.ExecuteTransaction(() => 
{ 
    bObject1_Repository.InsertBObject1(bObject1); 

    foreach (var bObject2 in bObject1.ListBObject2) 
     bObject2_Repository.InsertBObject2(bObject2); 
}); 

一切有利於我們的老「數據庫處理程序」;我們重複使用相同的事務並隱式地使用相同的連接...但是對於EF來說，變得非常棘手。爲了插入任何bObject2，首先你可能想要有一個自動生成。 bObject1的UID（在第一次插入後已知）...這在EF中不可用，除非在第一次插入後提前調用SaveChanges。一旦涉及多個「SaveChanges」調用，您就必須考慮這些事務會發生什麼。分佈式事務（DTC）可能是一個呃逆......當我們想要支持Oracle數據庫時，我們的項目就是這種情況......實際上我們被困在這裏。

我希望我能幫你從另一個角度看待事情......

除了注意：

將是很好聽到有人在EF和Oracle關於BL交易的使用經驗的意見;它也可以幫助我my question。