哪个是C＃和.NET的“最佳”数据访问框架/方法？
（编辑：我把它变成了社区维基，因为它更适合协作格式。）
从.NET访问SQL Server和其他数据库有很多种方法。 所有这些都有其优点和缺点，它永远不会是一个简单的问题，哪个是“最好的” – 答案永远是“它取决于”。
但是，我正在寻找在不同级别的系统环境中的不同方法和框架的高级别比较 。 例如，我认为对于快速而肮脏的Web 2.0应用程序，答案与内部企业级CRUD应用程序有很大不同。
我知道Stack Overflow上有很多问题涉及这个问题的子集，但我认为尝试构建一个汇总比较会很有用。 我将尽力更新问题并加以纠正和澄清。
到目前为止，这是我在高层次上的理解 – 但我确信这是错误的…我主要关注微软的方法来保持这一点。
ADO.NETentity framework
- 数据库不可知
- 好，因为它允许交换后端进出
- 糟糕，因为它可以达到性能，数据库供应商对它不太满意
- 似乎是MS未来的首选路线
- 复杂学习（但见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
我认为LINQ to SQL适用于针对SQL Server的项目。
如果我们针对不同的数据库，ADO.NETentity framework会更好。 目前我认为很多提供商可用于ADO.NETentity framework，PostgreSQL，MySQL，esql，Oracle等许多提供商（请访问http://blogs.msdn.com/adonet/default.aspx ）。
我不想再使用标准的ADO.NET了，因为这是浪费时间。 我总是去找ORM。
在20多个不同的C＃/ ASP.NET项目上工作后，我总是最终使用NHibernate 。 我经常从一个完全不同的堆栈开始–ADO.NET，ActiveRecord，手卷wierdness。 有很多原因可以解释为什么NHibernate可以在各种情况下工作，但绝对突出的是节省时间，特别是在链接到代码生成时。 您可以更改数据模型，并重建实体，但不需要更改大多数/所有其他代码。
MS确实有一种讨厌的习惯，即在这个领域推动技术并行现有的开源，然后在它们不起飞的时候丢弃它们。 有人记得ObjectSpaces吗？
添加了新技术：
现在使用Microsoft Sql Server for Linux in Beta，我认为不能与数据库无关。 .Net Core Path和MS-SQL路由允许您在完全没有Windows依赖性的Linux服务器上运行，如Ubuntu。
因此，imo，一个非常好的流程是不使用完整的ORM框架或数据控件，并利用SSDT Visual Studio项目（Sql Server数据工具）和Micro ORM的强大function。
在Visual Studio中，您可以将Sql Server项目创建为合法的Visual Studio项目。 这样做允许您通过表设计器或Visual Studio内部的原始查询编辑来创建整个数据库。
其次，您将获得SSDT的Schema Compare工具，您可以使用该工具将数据库项目与Microsoft Sql Server中的实时数据库进行比较并进行更新。 您可以将Visual Studio项目与服务器同步，从而导致项目中的更新发送到服务器。 或者，您可以将服务器与项目同步，从而更新源代码。 通过这条路线，您可以轻松获取DBA昨晚在维护中所做的更改，并使用简单的工具轻松推出新的开发更改，以便轻松实现新function。
使用相同的工具，您可以计算迁移脚本而无需实际运行它，如果您需要将其传递给运营部门并提交变更单，则该流程适用于该流程。
现在为我的MS-SQL数据库编写代码，我推荐PetaPoco。
因为PetaPoco与上述SSDT解决方案完美配合。 PetaPoco附带了T4文本模板，可用于生成所有数据实体类，并为您生成批量数据层类。
问题是，你必须自己编写查询，这不是一件坏事。
所以你最终得到这样的东西：
var people = dbContext.Fetch("SELECT * FROM People where Username Like '%@0%'", "bob"); PetaPoco为您自动处理@ 0参数化，它还具有用于构建查询的方便的Sql类。
此外，PetaPoco比EF6快一个数量级，比EF7快8倍。
总的来说，这个解决方案涉及使用SSDT进行SCHEMA管理，使用PetaPoco进行代码集成，从而获得高可维护性，定制性和非常好的性能。
这种方法唯一的缺点就是你很难将自己绑定到Microsoft Sql Server。 但是，imo，Microsoft Sql Server是最好的RDBM之一。
它有DBMail，Jobs，CLR对象function等等。 此外，Visual Studio和MS-SQL服务器之间的集成是惊人的，如果您选择不同的RDBMS，则无法获得任何此类服务。
我必须说，我从未使用NHibernate来开始使用所需的大量时间……浪费在XML设置上的时间。
我最近在MVC2中做了一个Web应用程序，在那里我选择了ADO Entities Framework，并且我一直使用Linq。
我必须说， 速度给我留下了深刻的印象 ！ 我们的网站每天有大约35 000个独立访问者，每天大约60Gb带宽（我通过在Amazon S3中托管所有静态文件来彻底减少这个60Gb的数量 – 我必须说，他们拥有Great .NET包装器）。
我会一直这样 。 它很容易启动（只需添加新的数据项，选择表格即可！对于数据库中的每个更改，我们只需刷新模型 – 只需2次点击即可自动生成）并且使用起来很有趣 – Linq规则！