我應該使用實體框架，而不是原始的ADO.NET

Question

我是CSLA和實體框架的新手。我正在創建一個新的CSLA/Silverlight應用程序，它將取代12年前的Win32 C++系統。舊系統使用自定義的DCOM業務對象庫並使用ODBC訪問SQL Server。新系統不會立即取代舊系統 - 它們必須在未來幾年與同一個數據庫共存。

起初我以爲EF是最近最偉大的一條路。在製作一個小型EF模型並且只有2個CSLA可編輯根對象（我最終將擁有數百個對象，因爲我的數據庫有800多個表），我非常懷疑EF的使用。

在當前系統中，我需要多次對查詢進行細節性能調整，因爲對生成的SQL進行了100％的控制，所以我可以做到這一點。但是，EF似乎在幕後發生了這麼多事情，我失去了這種控制。像http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html這樣的文章不能幫助我對EF的印象。

人們似乎喜歡EF，因爲LINQ到EF，但由於我的標準是作爲標準對象在客戶端和服務器之間傳遞，所以似乎我可以在沒有LINQ的情況下輕鬆構建查詢。我理解在WCF RIA中有查詢投影（或者類似的東西），我可以在客戶端執行LINQ，它在轉換爲實際SQL之前移動到服務器，所以在這種情況下，我可以看到EF的好處，但不能在CSLA 。

如果我使用原始的ADO.NET，我會後悔5年後的決定嗎？

最近有沒有人做過這個選擇，你走哪條路？

Answer 1

在你的情況下，我仍然會選擇EF來完成手工操作。

爲什麼？ EF - 特別是在.NET 4中 - 已經相當成熟。它將允許您執行大部分數據庫操作比使用全部手工編碼數據訪問代碼更簡單且代碼少得多。

並且在確實需要絕對最大性能的情況下，您可以隨時插入用於插入，更新和刪除的存儲過程，然後使用EF4而不是實時創建SQL語句的默認行爲。

EF4具有存儲好得多PROC整合，這真的打開了兩全其美：

• 使用EF的高生產率的80％情況下，性能是不是最重要
• 微調和手工存儲特效剩餘的20％，並將其插入EF4

看到一些資源：

• Using Stored Procedures for Insert, Update and Delete in an Entity Data Model
• Practical Entity Framework for C#: Stored Procedures (video)

Answer 2

你似乎有要求的混合和解決方案的組合。

我通常會給每個需求分配一個基本的，很好的，非必要的。然後看看有什麼作用。

我同意@marc_s的說法，你可以擁有兩全其美。

我會說的唯一的另一件事是，如果這個解決方案將在未來5年左右，你有沒有考慮過單元測試？

有plentyofexamples關於如何使用EF進行設置。 （我個人避免ADO.Net只是因爲單元測試的問題分離太複雜了。）

有沒有簡單的解決方案。我會在你的項目中選擇一項需要一天左右的功能。嘗試不同的方法（原始的SQL，EF，EF +存儲過程），看看有什麼作用！

Answer 3

客觀看待CSLA - 調用'DataPortal'並查看調用堆棧。

接下來，將這些類放在CI構建服務器上，該構建服務器存儲運行時數據並提供一系列運行的散點圖。

接下來，看看創建的代碼。問問自己，如何根據靜態創建者與受保護/私有構造函數的類來使用依賴注入等方法。

接下來，看看'CSLA'班承擔了多少責任。

最後問問自己，是否在每個環境中創建具有不同構造函數的對象是有意義的，並問自己如何對這些對象進行單元測試。