ADO.NET實體框架或ADO.NET

Question

我正在開始一個基於ASP.NET和Windows服務器的新項目。

該應用程序計划相當大，並為大量客戶提供高頻率和高頻率。 改變數據。

我之前使用Linq-To-Sql或Ado.Net創建了項目。

我對這個項目的計划是使用VS2010和新的EF4框架。

• 聽到其他程序員關於使用Entity Framework進行開發的選項會很棒

• 以往經驗的利弊？

• 您認為EF4是否已准備好投入生產？

• 我應該冒風險還是堅持使用普通的舊ADO.NET？

Answer 1

EF4是否真的准備好生產有點難以說明，因為它還沒有正式發布......但所有的初步經驗和報告似乎都表明它非常好。

但是：你需要考慮EF試圖解決的問題; 它是一個雙層方法，一層映射到數據庫中的物理存儲架構（並支持多個后端），第二層是您編程的概念模型。 當然，需要在這兩個層之間進行映射。

因此，如果您有大量的表，如果您有多個后端需要支持，如果您需要能夠將物理模式映射到不同的概念模式，那么EF4非常棒，等等。 它非常適合復雜的企業級應用程序。

但這需要付出代價 - 這些額外的層確實會對性能，復雜性和可維護性產生影響。 如果您需要這些功能，您將很樂意支付這個價格，毫無疑問。 但你需要嗎？

當然，你可以回到直接的ADO.NET - 但你真的想再次使用DataTables，DataRows和無類型的Row["RowName"]構造？ 真？？？

所以我的建議如下：

• 如果您只需要SQL Server作為后端
• 如果您有一個相當簡單和直接的映射，將一個數據庫表映射到模型中的一個實體對象

然后：使用Linq-to-SQL ！ 為什么不？？ 它仍然完全得到微軟在.NET 4中的支持 - 哎呀，他們甚至做了錯誤修正並添加了一些零碎的東西 - 它很快，它很有效，它很精簡和平均 - 所以為什么不呢？

Answer 2

我的建議是同時使用。 起初我以為我只會使用linq來sql而且永遠不必再次觸摸ado.net（是什么讓我開心大笑）。

現在我正在使用兩者，因為有些東西linq to sql（和任何像EF這樣的ORM）都做不到。 我不得不做一些大量插入，我首先使用linq到sql做了500次記錄，花了6分鍾（驗證規則休息2分鍾就是插入數據庫）。

我將其更改為sql批量復制，現在它已降至2分4秒（所有插入時間為4秒）

但是就像marc_s說我真的不想擺弄DataTables，DataRows和無類型的Row [“RowName”]。

假設我的表格長達10列並且稱為表A.我做的是我使用linq to sql並創建了一個表A類（新的TableA（））對象並用數據填充它。 然后我將此對象傳遞給創建數據行的方法。

因此linq to sql節省了一些時間，因為我可能會創建一個類，因為我不想將10個參數傳遞給產生數據行的方法。 我也覺得它給了一些類型，因為你必須傳遞正確的對象來使用該方法，因此傳遞錯誤數據的機會更少。

最后，您仍然可以使用linq to sql來調用存儲過程，這就像一行代碼。

因此，當你注意到linq到sql（或者在你的情況下為EF）很慢時，我會使用兩者，然后只需編寫SP並通過EF調用它。 如果你需要直接做ado.net評估你需要做什么，也許你可以在大多數代碼中使用EF（所以你至少可以使用對象），而且只用於ado.net的那一小部分我用的是什么sql批量復制。

Answer 3

EF 4現在更像是LINQ to SQL，在很好的方面; 它在對象中有FK鍵，在對象集中添加​​方法，以及許多其他不錯的功能。 設計人員得到了很大的改進，主要的優點是它可以與SQL和Oracle一起使用，也許還有其他一些（只要提供者支持它），而不是僅使用SQL Server的LINQ to SQL。

EF是未來; ADO.NET數據服務是一個Web服務添加，並且它支持POCO和T4生成，並且任何新功能都將支持此功能（LINQ to SQL僅維護，數據集將不再獲得任何更改）。

HTH。