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

Which is the “best” data access framework/approach for C# and .NET?

(编辑：我把它变成了一个社区维基，因为它更适合于协作格式。)

有很多方法可以从.NET访问SQL Server和其他数据库。所有人都有各自的优缺点，这永远不会是一个简单的"最佳"问题——答案永远是"视情况而定"。

然而，我正在寻找一个在不同系统层次背景下的不同方法和框架的高层比较。例如，我可以想象，对于一个快速而肮脏的Web2.0应用程序，答案将与内部企业级CRUD应用程序非常不同。

我知道在处理这个问题的子集时，有许多关于堆栈溢出的问题，但是我认为尝试构建一个摘要比较是有用的。我将努力在我们进行过程中用更正和澄清来更新这个问题。

到目前为止，这是我在高层次上的理解——但我确信这是错误的……我主要关注微软的方法来保持这一点。

ADO.NET实体框架

数据库不可知论
很好，因为它允许交换后端进出
不好，因为它会影响性能，数据库供应商对此不太满意
似乎是微软未来的首选路线
学习起来很复杂(尽管，见267357)
它通过LINQ访问实体，从而提供ORM，从而允许在代码中进行抽象。

解决并发冲突

不确定的未来(请参见Linq to SQL是否真的死了？)
易学(？)
仅适用于MS SQL Server
另见Linq的优缺点

"标准"ado.net

没有ORM
没有抽象，因此您可以返回到"滚动自己的"并使用动态生成的SQL。
直接访问，允许潜在的更好的性能
这与是否关注对象或关系数据这一由来已久的争论有关，当然，答案是"这取决于大部分工作在哪里"，而且由于这是一个无法回答的问题，希望我们不必过多地讨论这个问题。imho，如果您的应用程序主要处理大量的数据，那么在前端代码中将其抽象为对象是没有意义的，您最好使用存储过程和动态SQL在后端尽可能多地进行工作。然而，如果您主要有用户交互，导致数据库交互达到数十或数百行，那么ORM完全有意义。因此，我想我对老式ADO.NET的看法是，在这种情况下，您可以操作和修改大型数据集，在这种情况下，您可以直接访问后端。
当然，另一种情况是，您必须访问已经由存储过程保护的遗留数据库。

ASP.NET数据源控件

这些是完全不同的东西还是仅仅是标准ADO.NET之上的一层？-如果有DAL或者实现了LINQ或实体，您真的会使用这些吗？

NHiBiNATE

似乎是一个非常强大的ORM？
开放源代码

其他相关环节；NHibernate或Linq to SQL实体框架与Linq to SQL

相关讨论

新增新技术：

随着微软SQL Server在Linux测试版的推出，我认为不需要数据库不可知论是可以的。.NET核心路径和MS-SQL路由允许您完全在Ubuntu等Linux服务器上运行，而不需要依赖Windows。

因此，在IMO中，一个非常好的流程是不使用完整的ORM框架或数据控件，并且利用SSDT Visual Studio项目(SQL Server数据工具)和微型ORM的强大功能。

在Visual Studio中，可以将SQL Server项目创建为合法的Visual Studio项目。这样做允许您通过表设计器或直接在Visual Studio中编辑原始查询来创建整个数据库。

其次，您可以使用ssdt的模式比较工具将数据库项目与Microsoft SQL Server中的活动数据库进行比较，并对其进行更新。您可以将Visual Studio项目与服务器同步，从而使项目中的更新输出到服务器。或者，您可以将服务器与项目同步，从而更新源代码。通过这条路径，您可以很容易地了解DBA昨晚在维护中所做的更改，并使用一个简单的工具轻松地将新的开发更改推到新特性上。

使用相同的工具，您可以在不实际运行迁移脚本的情况下计算迁移脚本，如果您需要将其传递给操作部门并提交变更单，那么它将为该流工作。

现在，对于使用MS-SQL数据库编写代码，我推荐Petapoco。

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

关键是，你必须自己写查询，这不是一件坏事。

所以你最终会得到这样的结果：

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

Petapoco自动为您处理参数化@0，它还具有方便的用于构建查询的SQL类。

此外，Petapoco比EF6快一个数量级，比EF7快8倍以上。

因此，总的来说，这个解决方案涉及到使用ssdt进行模式管理，以及petapoco进行代码集成，以获得高可维护性、定制性和非常好的性能。

这种方法唯一的缺点是，您很难将自己绑定到Microsoft SQL Server。但是，在IMO中，Microsoft SQL Server是目前最好的RDBM之一。

它有dbmail、jobs、clr对象功能，等等。另外，Visual Studio和MS-SQL Server之间的集成非常出色，如果您选择不同的RDBMS，则不会得到任何集成。

在完成了20多个不同的C/ASP.NET项目后，我总是使用NHibernate。我经常从一个完全不同的堆栈开始——ado.net、activerecord、手工卷wierdness。NHibernate可以在多种情况下工作有很多原因，但对我来说最突出的是节省时间，尤其是与代码生成相关联时。您可以更改数据模型，并重建实体，但大多数/所有其他代码不需要更改。

微软确实有一个讨厌的习惯，在这个领域推动与现有开放源码并行的技术，然后在它们不起飞时放弃它们。有人记得ObjectSpace吗？