哪个是C#和.NET的“最佳”数据访问框架/方法？

Question

(编辑：我将其更改为社区维基，因为这更适合协作格式。)

有众多的方法可以从.NET访问SQL Server和其他数据库。所有方法都有其优缺点，它永远不会是一个简单的问题，哪种方法是“最好的” - 答案总是“取决于情况”。

然而，我正在寻找在不同级别的系统上比较不同方法和框架的高级别概述。例如，我想象对于一个快速且简单的Web 2.0应用程序，答案会与内部企业级CRUD应用程序非常不同。

我知道Stack Overflow上有很多关于此问题子集的问题，但我认为尝试建立摘要比较会很有用。我将努力更新问题并进行更正和澄清。

到目前为止，这是我在高层次上的理解 - 但我肯定是错的...... 我主要关注微软的方法以保持专注。

ADO.NET Entity Framework

• 数据库无关
• 好处是它允许在后端之间交换
• 不好的地方是它可能影响性能，数据库供应商对此也不太满意
• 似乎是微软未来的首选路线
• 学习起来很复杂（尽管参见267357）
• 通过LINQ to Entities访问，因此提供ORM，从而允许在代码中进行抽象

LINQ to SQL

• 未来不确定 (参见LINQ to SQL是否已死？)
• 易于学习 (?)
• 仅适用于MS SQL Server
• 另请参阅LINQ的优缺点

“标准”ADO.NET

• 没有ORM
• 没有抽象层，因此您需要回到“自己编写”并使用动态生成的SQL
• 直接访问，可能具有更好的性能
• 这与关注对象还是关系数据的古老辩论息息相关，当然答案是“取决于主要工作在哪里”，由于这是一个无法回答的问题，希望我们不必太过深入。在我看来，如果您的应用程序主要是操作大量数据，则不应将其过多地抽象成前端代码中的对象，最好使用存储过程和动态SQL尽可能多地在后端执行工作。而如果您主要有用户交互引起的数据库交互，涉及几十或几百行，则ORM完全有意义。因此，我想为传统的ADO.NET辩护的情况是您操纵和修改大型数据集的情况，这样您将从直接访问后端中受益。
• 当然，另一种情况是您必须访问由存储过程保护的传统数据库。

ASP.NET数据源控件

这些是否完全不同或仅是标准ADO.NET上的一层？ - 如果您有DAL或实现了LINQ或实体，则确实会使用这些吗？

NHibernate

• 似乎是一个非常强大的ORM?
• 开源

其他相关链接；

NHibernate或LINQ to SQL Entity Framework与LINQ to SQL 这些问题都涉及到数据访问技术的选择。NHibernate和Entity Framework是ORM（对象关系映射）框架，它们可以将数据库中的表映射到.NET对象，并提供了一种方便的方式来进行CRUD操作。而LINQ to SQL则是一个轻量级的ORM框架，专门用于SQL Server数据库。

如果你需要支持多个数据库，或者需要更高级的映射功能，NHibernate和Entity Framework可能更适合你。但是，如果你只需要使用SQL Server，并且对映射要求不高，那么LINQ to SQL可能是更好的选择。

总之，选择哪种技术取决于你的具体需求和偏好。

- Frans

---

你好。请问你能给我一些关于这个说法的参考资料吗？“这样做会影响性能，而且数据库供应商也不太喜欢它。” - gbjbaanb

随着EF5和现在的EF6，性能得到了极大的提升。 - jessehouwing

Answer 1

我认为LINQ to SQL适用于针对SQL Server的项目。

如果我们的目标是不同的数据库，ADO.NET Entity Framework会更好。目前，我认为有很多提供程序可用于ADO.NET Entity Framework，例如PostgreSQL、MySQL、esql、Oracle等（请查看http://blogs.msdn.com/adonet/default.aspx）。

我不想再使用标准的ADO.NET了，因为这是浪费时间。我总是选择ORM。

- Priyan R

---

ADO.NET Entity Framework旨在在所有方面都优于Linq to SQL，微软实际上打算在某个时候废弃Linq to SQL并推出Entity Framework，但他们意识到Linq to SQL为程序员提供的简单易用性和效率使其太受欢迎，以至于他们不能仅仅废弃它。 - Eduardo Wada

Answer 2

我曾经参与过20多个不同的C#/ASP.NET项目，我总是最终使用NHibernate。我经常从完全不同的堆栈开始 - ADO.NET、ActiveRecord、手工编写的怪异代码。NHibernate 可以在各种情况下工作的原因有很多，但对我来说最突出的是节省时间，特别是与代码生成相关联时。您可以更改数据模型，实体将重新构建，但大部分/所有其他代码不需要更改。

微软在这个领域有一个讨厌的习惯，即推动与现有开源技术平行的技术，然后在它们不受欢迎时放弃它们。有人还记得ObjectSpaces吗？

- MrTelly

---

微软有一个开发新的数据库访问技术的习惯 - 还记得 DAO、RDO、RDS、JRO 和 SQLXML 吗？哦，现在又来了 OracleClient！ - gbjbaanb

NHibernate 中一些显著的荒谬之处包括：（1）陡峭的学习曲线，（2）难以调试 .hbm 文件，（3）市场上缺乏易懂的书籍......截至 2011 年。 - user366312

Answer 3

针对新技术的补充：

现在Microsoft Sql Server已经推出了Linux版Beta版本，因此不必考虑数据库无关性。使用.Net Core Path和MS-SQL路线可以在Linux服务器（如Ubuntu）上运行，完全不需要Windows依赖。

因此，在我看来，一个非常好的方案是不使用完整的ORM框架或数据控件，而是利用SSDT Visual Studio项目（Sql Server Data Tools）和Micro ORM的强大功能。

在Visual Studio中，您可以创建一个Sql Server项目作为合法的Visual Studio项目。这样做可以让您通过表设计师或原始查询编辑器在Visual Studio内部创建整个数据库。

其次，您可以使用SSDT的Schema Compare工具将数据库项目与Microsoft Sql Server中的实时数据库进行比较并更新它。您可以将您的Visual Studio项目与服务器同步，使得项目中的更新传递到服务器。或者您可以将服务器与项目同步，使得源代码更新。通过这种方式，您可以轻松获取DBA在维护中所做的更改，并使用简单的工具轻松推出新功能的开发更改。

使用相同的工具，您可以计算迁移脚本，而无需实际运行它。如果您需要将其提交给操作部门并提交变更订单，则可以使用该流程。

现在，针对您的MS-SQL数据库编写代码，我建议使用PetaPoco。

因为PetaPoco与上述SSDT解决方案完全配合。PetaPoco带有T4文本模板，您可以使用它来生成所有数据实体类，并为您生成批量数据层类。

唯一的缺点是您必须自己编写查询语句，但这并不是什么坏事。

因此，您最终会得到如下结果：

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

PetaPoco会自动处理参数化的@0，同时还有方便的Sql类来构建查询语句。此外，PetaPoco比EF6快一个数量级，比EF7快8倍以上。因此，这个解决方案涉及使用SSDT进行SCHEMA管理，以及使用PetaPoco进行代码集成，从而获得高可维护性、可定制性和非常好的性能。唯一的缺点是，你将自己硬绑定到Microsoft Sql Server上。然而，在我看来，Microsoft Sql Server是最好的关系型数据库之一。它具有DBMail、Jobs、CLR对象功能等等。此外，Visual Studio与MS-SQL服务器之间的集成非常出色，如果选择其他RDBMS则无法获得这些优势。

- Ryan Mann

---

2023年更新/EF Core等。我仍然会使用SSDT和Sql Server，但我会在数据库优先模式下使用EF Core（使用EF来执行所有查询等操作，但不要将其用于迁移）。 - Ryan Mann

Answer 4

我必须说，我从未使用NHibernate，因为需要花费很长时间来开始使用...浪费在XML设置上的时间。

最近我做了一个MVC2的web应用程序，在那里我选择了ADO实体框架，并且一直在使用Linq。

我必须说，速度令人印象深刻！我们的网站每天有大约35,000个独立访客，每天有大约60 GB的带宽（通过在Amazon S3中托管所有静态文件，我将这个数字大大降低 - 他们拥有伟大的.NET封装器，我必须说）。

我总是会这样做。它很容易开始（只需添加新数据项、选择表格即可！对于数据库中的每个更改，我们只需刷新模型 - 只需两个点击即可自动生成）而且非常有趣 - Linq牛逼！

- balexandre