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

Posted 2023-03-31

【中文标题】哪个是 C# 和 .NET 的“最佳”数据访问框架/方法？

【英文标题】：Which is the "best" data access framework/approach for C# and .NET?

【发布时间】：2010-10-14 00:30:30

【问题描述】：

（编辑：我将其设为社区 wiki，因为它更适合协作格式。）

有多种方法可以从 .NET 访问 SQL Server 和其他数据库。各有利弊，这绝不是一个简单的问题，即哪个是“最好的”——答案永远是“视情况而定”。

但是，我正在寻找在不同系统级别的上下文中对不同方法和框架进行高级比较。例如，我可以想象，对于一个又快又脏的 Web 2.0 应用程序，答案将与内部企业级 CRUD 应用程序大不相同。

我知道 Stack Overflow 上有很多关于这个问题的子集的问题，但我认为尝试建立一个摘要比较会很有用。我将努力在我们进行时通过更正和澄清来更新问题。

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

ADO.NET Entity Framework

与数据库无关 很好，因为它允许换入和换出后端 不好，因为它会影响性能并且数据库供应商对此不太满意 似乎是 MS 未来的首选路线 学习起来很复杂（不过，请参阅 267357） 它通过LINQ to Entities 访问，因此提供了ORM，从而允许在您的代码中进行抽象

LINQ to SQL

不确定的未来（见Is LINQ to SQL truly dead?） 易于学习 (?) 仅适用于 MS SQL Server 另见Pros and cons of LINQ

“标准”ADO.NET

没有 ORM 没有抽象，因此您可以回到“自己动手”并使用动态生成的 SQL 直接访问，可能获得更好的性能 这与关于是关注对象还是关系数据的古老争论有关，答案当然是“这取决于大部分工作在哪里”，因为这是一个无法回答的问题，希望我们不必过多考虑。恕我直言，如果您的应用程序主要是处理大量数据，那么将其过多地抽象为前端代码中的对象是没有意义的，您最好使用存储过程和动态 SQL 来完成尽可能多的工作可以在后端。然而，如果您主要有导致数十或数百行级别的数据库交互的用户交互，那么 ORM 是完全有意义的。所以，我想我对老式 ADO.NET 的论证是在您操作和修改大型数据集的情况下，在这种情况下，您将受益于对后端的直接访问。 当然，另一种情况是您必须访问已由存储过程保护的旧数据库。

ASP.NET 数据源控件

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

NHibernate

好像是一个很强大很强大的ORM？ 开源

其他一些相关链接； NHibernate or LINQ to SQL Entity Framework vs LINQ to SQL

【问题讨论】：

嗨。你能给我一些关于这个声明的参考吗：“不好，因为它会影响性能并且数据库供应商对此不太满意”

使用 EF5 和现在的 6，性能有了很大提高。

【参考方案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。

【讨论】：

ADO.NET Entity Framework 旨在在所有方面都优于 Linq to SQL，微软实际上打算在某个时候随着 Entity Framework 的发布而弃用 Linq to SQL，但他们意识到简单， Linq to SQL 为程序员提供的易用性和效率使其太受欢迎，以至于他们不赞成使用它。

【参考方案2】：

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

MS 确实有一个讨厌的习惯，即在该领域推动与现有开源并行的技术，然后在它们没有起飞时放弃它们。有人记得 ObjectSpaces 吗？

【讨论】：

见鬼，MS 有开发新数据库访问技术的习惯——还记得 DAO、RDO、RDS、JRO 和 SQLXML 吗？哦，现在是 OracleClient！

NHibernate 的一些突出的荒谬之处是 (1) 陡峭的学习曲线，(2) 难以调试 .hbm 文件，(3) 市场上缺乏可理解的书籍...... 2011 年。

【参考方案3】：

为新技术添加：

现在 Microsoft Sql Server 推出了用于 Linux 的 Beta 版，我认为不与数据库无关是可以的。 .Net Core Path 和 MS-SQL 路由允许您在完全不依赖 Windows 的情况下在 Ubuntu 等 Linux 服务器上运行。

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

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

其次，您将获得 SSDT 的架构比较工具，您可以使用该工具将您的数据库项目与 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。但是，imo，Microsoft Sql Server 是目前最好的 RDBM 之一。

它有 DBMail、Jobs、CLR 对象功能等等。此外，Visual Studio 和 MS-SQL 服务器之间的集成非常出色，如果您选择不同的 RDBMS，您将无法获得任何这些。

【参考方案4】：

我必须说，我从来没有使用 NHibernate 需要开始使用的大量时间...浪费在 XML 设置上的时间。

我最近在 MVC2 中做了一个 Web 应用程序，我确实选择了 ADO 实体框架，并且一直使用 Linq。

我必须说，我对速度印象深刻！我们的网站每天有大约 35 000 名唯一访问者，每天大约有 60Gb 带宽（我通过在 Amazon S3 中托管所有静态文件从根本上减少了这个 60Gb 的数字 - 我必须说，他们拥有很棒的 .NET 包装器）。

我会一直走这条路。它很容易上手（只需添加新的数据项、选择表即可！对于数据库中的每次更改，我们只需刷新模型 - 只需单击 2 次即可自动完成）而且使用起来很有趣 - Linq 规则！