C# 和 .NET 的“最佳”數據訪問框架/方法是哪個？

Question

（編輯：我將其設為社區 wiki，因為它更適合協作格式。）

有多種方法可以從 .NET 訪問 SQL 服務器和其他數據庫。 所有人都有其優點和缺點，這絕不是一個簡單的問題，即哪個是“最好的”——答案將永遠是“視情況而定”。

但是，我正在尋找在不同系統級別的上下文中對不同方法和框架進行高級別比較。 例如，我想對於快速而骯臟的 Web 2.0 應用程序，答案將與內部企業級 CRUD 應用程序大不相同。

我知道 Stack Overflow 上有很多關於這個問題的子集的問題，但我認為嘗試建立一個摘要比較會很有用。 當我們 go 時，我將努力通過更正和澄清來更新問題。

到目前為止，這是我在高層次上的理解——但我確信這是錯誤的……我主要關注微軟的方法來保持這一點。

ADO.NET 實體框架

• 與數據庫無關
• 很好，因為它允許交換后端進出
• 不好，因為它會影響性能並且數據庫供應商對此不太滿意
• 似乎是MS未來的首選路線
• 學習起來很復雜（不過，請參閱267357 ）
• 它通過LINQ 訪問到實體，因此提供 ORM，從而允許在您的代碼中進行抽象

LINQ 至 SQL

• 不確定的未來（見LINQ 到 SQL 真的死了嗎？ ）
• 簡單易學 （？）
• 僅適用於 MS SQL 服務器
• 另請參閱LINQ 的優缺點

“標准”ADO.NET

• 無 ORM
• 沒有抽象，所以你回到“自己動手”並使用動態生成的 SQL
• 直接訪問，可實現更好的性能
• 這與關於是否關注對象或關系數據的古老爭論有關，答案當然是“這取決於大部分工作在哪里”，因為這是一個無法回答的問題，希望我們不要必須要 go 到那個太多。 恕我直言，如果您的應用程序主要是處理大量數據，那么將其過多地抽象為前端代碼中的對象是沒有意義的，您最好使用存儲過程和動態 SQL 來完成盡可能多的工作可以在后端。 然而，如果您主要有導致數十或數百行級別的數據庫交互的用戶交互，那么 ORM 完全有意義。 所以，我想我對好的老式 ADO.NET 的論點是在您操作和修改大型數據集的情況下，在這種情況下，您將受益於直接訪問后端。
• 當然，另一種情況是您必須訪問已經由存儲過程保護的遺留數據庫。

ASP.NET 數據源控件

這些是完全不同的東西還是只是標准 ADO.NET 的一層？ - 如果您有 DAL 或者您實施了 LINQ 或實體，您真的會使用這些嗎？

NHibernate

• 好像是很厲害很厲害的ORM？
• 開源

其他一些相關鏈接； NHibernate or LINQ to SQL Entity Framework vs LINQ to SQL

Answer 1

我認為 LINQ 到 SQL 適用於針對 SQL 服務器的項目。

如果我們針對不同的數據庫，ADO.NET 實體框架會更好。 Currently I think a lot of providers are available for ADO.NET Entity Framework, Provider for PostgreSQL, MySQL, esql, Oracle and many other (check http://blogs.msdn.com/adonet/default.aspx ).

我不想再使用標准的 ADO.NET 了，因為這很浪費時間。 對於 ORM，我總是使用 go。

Answer 2

為新技術添加：

微軟 Sql 服務器現在在測試版中用於 Linux，我認為不與數據庫無關是可以的。 .Net Core Path 和 MS-SQL 路由允許您在 Linux 服務器上運行，例如 Ubuntu，完全沒有 windows 依賴項。

因此，imo，一個非常好的流程是不使用完整的 ORM 框架或數據控件，並利用 SSDT Visual Studio Projects（Sql Server 數據工具）和 Micro ORM 的強大功能。

在 Visual Studio 中，您可以將 Sql 服務器項目創建為合法的 Visual Studio 項目。 這樣做允許您通過表設計器或直接在 Visual Studio 中進行原始查詢編輯來創建整個數據庫。

其次，您將獲得 SSDT 的架構比較工具，您可以使用該工具將您的數據庫項目與 Microsoft Sql 服務器中的實時數據庫進行比較並更新它。 您可以將 Visual Studio 項目與服務器同步，從而將項目中的 go 更新到服務器。 或者您可以將服務器與您的項目同步，從而更新您的源代碼。 通過這條路線，您可以輕松獲取 DBA 昨晚在維護中所做的更改，並使用簡單的工具輕松推出新功能的新開發更改。

使用相同的工具，您無需實際運行即可計算遷移腳本，如果您需要將其傳遞給運營部門並提交變更單，它適用於該流程。

現在要針對您的 MS-SQL 數據庫編寫代碼，我推薦 PetaPoco。

因為 PetaPoco 與上述 SSDT 解決方案完美內聯。 PetaPoco 帶有 T4 文本模板，您可以使用它來生成所有數據實體類，並為您生成批量數據層類。

問題是，您必須自己編寫查詢，這不是一件壞事。

所以你最終會得到這樣的結果：

var people = dbContext.Fetch<Person>("SELECT * FROM People where Username Like '%@0%'", "bob");

PetaPoco 會自動為您處理參數化@0，它還有方便的 Sql class 用於構建查詢。

此外，PetaPoco 比 EF6 快一個數量級，比 EF7 快 8 倍以上。

所以總的來說，這個解決方案涉及使用 SSDT 進行 SCHEMA 管理，使用 PetaPoco 進行代碼集成，以獲得高可維護性、定制化和非常好的性能。

這種方法的唯一缺點是您很難將自己綁定到 Microsoft Sql 服務器。 但是，imo，Microsoft Sql 服務器是目前最好的 RDBM 之一。

它有 DBMail、Jobs、CLR object 功能等等。 此外，Visual Studio 和 MS-SQL 服務器之間的集成非常出色，如果您選擇不同的 RDBMS，您將不會得到任何這些。

Answer 3

在從事過 20 多個不同的 C#/ASP.NET 項目之后，我總是最終使用NHibernate 。 我經常從一個完全不同的堆棧開始——ADO.NET、ActiveRecord、手卷怪異。 NHibernate 可以在各種情況下工作的原因有很多，但對我來說絕對突出的是節省時間，尤其是與代碼生成相關聯時。 您可以更改數據模型，並重建實體，但大多數/所有其他代碼不需要更改。

MS 確實有一個討厭的習慣，即在該領域推動與現有開源平行的技術，然后在它們沒有起飛時放棄它們。 有人記得 ObjectSpaces 嗎？

Answer 4

我必須說，我從來沒有使用過 NHibernate需要開始使用的大量時間......浪費在XML 設置上的時間。

我最近在MVC2中做了一個 web 應用程序，我確實選擇了ADO 實體框架，並且一直使用 Linq。

我必須說，速度給我留下了深刻的印象，我們的網站每天有大約 35 000 名唯一訪問者，每天大約 60Gb 帶寬（我通過在 Amazon S3 中托管所有 static 文件從根本上減少了這個 60Gb 的數字 - 他們很棒的 .NET 包裝器有。我必須說）。

我會一直這樣 go 。 它很容易上手（只需添加新的數據項，選擇表就可以了！對於數據庫中的每一次更改，我們只需要刷新 model - 只需單擊 2 次即可自動生成）而且使用起來很有趣 - Linq 規則！