使用Linq to Entities時，是否需要單獨的數據層？

Question

當使用Linq to Entities時，是否仍然需要使用單獨的數據層來抽象數據庫訪問，還是可以接受的（或者甚至推薦）直接從代碼隱藏中製作Linq查詢（因爲獲取，添加，更新和刪除功能已經內置到實體框架中）？

Answer 1

我們使用Linq到EF，我們還有一個單獨的數據層。

部分是因爲如果我們不想再使用EF，或者如果我們需要支持EF不支持的數據庫，未來會發生什麼。抽象的一部分是每層都可以改變而不影響其他層。

但也因爲我們的數據層比簡單的加載和保存數據對象更復雜一點。從EF加載對象後，它們將與EF數據上下文完全斷開連接並轉換爲業務對象。 EF生成的數據對象從不暴露在數據層之上。 （這是因爲EF對斷開連接的客戶端 - 服務器應用程序的不良支持，因此我們必須自己管理該部分）

Answer 2

在我看來，實體框架是DAL。儘管在某些應用程序中我已經將它包裝了，因爲它仍然是一種特定的技術，我嘗試從應用程序整體抽象特定技術。因此，如果需要轉到另一個或更改業務對象的創建方式，則可以在不影響應用程序其餘部分的情況下執行此操作。

由於這真的適用於所有OR/M工具，所以您會收到一些有趣的回覆。

Answer 3

這取決於死線的接近程度，您希望開發的應用程序有多大，可能還有更多。

我會說是，執行一個數據層。例如：如果應用程序需要使用Oracle數據庫運行（將來有一段時間），那麼情況會非常糟糕。

Answer 4

Linq-to-Entities是一個實現細節。數據層旨在將實現從與數據的交互中抽象出來。如果您發現Linq-to-entities不合適，並且必須更改實現，這可確保系統的健壯性。因此，是的，你仍然需要一個數據層。