如何创建合适的数据库层？答案

【问题标题】：How to create a proper database layer?如何创建合适的数据库层？
【发布时间】：2009-10-13 15:38:01
【问题描述】：

目前我使用很多 ado.net 类（SqlConnection、SqlCommand、SqlDataAdapter 等）来调用我们的 sql 服务器。这是个坏主意吗？我的意思是它有效。但是我看到很多文章使用 ORM、nHibernate、subsonic 等来连接 SQL。为什么那些更好？我只是想了解为什么我需要改变这个？

更新：

我确实查看了以下关于将 nHibernate 与存储过程一起使用的教程。

http://ayende.com/Blog/archive/2006/09/18/UsingNHibernateWithStoredProcedures.aspx

但在我看来，这是一种矫枉过正的方式。为什么我必须创建一个映射文件？即使我创建了一个映射文件并假设我的表发生了变化，那么我的代码也将不再工作。但是，如果我使用 ado.net 返回一个简单的数据表，那么我的代码仍然可以工作。我在这里遗漏了什么？

【问题讨论】：

标签： database ado.net

【解决方案1】：

使用基本的 ADO.NET 类没有任何问题。

您可能只需要做很多不必要的手动工作。如果你例如使用 SqlCommand 和 SqlDataReader 从表中选择您的前 10 名客户，这取决于您对结果进行迭代，提取每一项数据（如客户编号、客户名称等），然后您正在处理与数据库结构非常密切，例如行和列。在某些情况下这很好，但在其他情况下工作量太大。

ORM 为您提供的是为您处理大量此类“繁重的工作”。您只需告诉它获取您的前 10 名客户的列表 - 作为“客户”对象。 ORM 将开始抓取数据（很可能使用 SqlCommand、SqlDataReader），然后提取零碎的数据，并为您组装好、易于使用的“客户”对象，这些对象更易于使用，因为它们是您的代码正在处理的内容 - 客户对象。

因此，使用 ADO.NET 绝对没有任何问题，如果您知道它是如何工作的，这是一件好事 - 但是 ORM 可以为您节省大量繁琐、重复和无聊的繁重工作，让您专注于真正的业务问题在对象级别上。

马克

【讨论】：

但是控制正在使用的sql不是很好吗？我使用存储过程（不要因此而杀了我），但是它们为我们工作。为什么我要修复没有损坏的东西？
是和否- 是的，如果您真的很擅长编写 SQL。但在至少 90% 的情况下，ORM 生成的 SQL 至少与普通开发人员可以生成的手工 SQL 一样好。这里真的没有大的性能损失。大多数 ORM 会很乐意支持 SELECT、UPDATE、INSERT 和 DELETE 操作的存储过程 - 这样，如果您觉得这样更舒服，您最终可以再次完全控制您的 SQL。

【解决方案2】：

首先，ORM 在生成 SQL 查询方面可能比普通的非 SQL 专业人士 Joe 做得更好：)

其次，ORM 是一种在一定程度上“标准化”你的 DAL 的好方法，增加了不同项目的灵活性。

最后，使用良好的 ORM，您可能会更轻松地替换底层数据源，因为良好的 ORM 将有许多不同的方言。当然，这只是一个额外的好处:)

【讨论】：

【解决方案3】：

ORM 非常适合避免代码重复。您经常会发现您的对象模型和数据库模型彼此非常接近，并且无论何时添加字段，您都会将其添加到数据库、对象、sql 语句以及其他任何地方。如果您使用 ORM，那么您只需在一个地方更改您的代码，然后它会为您构建其余部分。

至于性能，这可以是任何一种方式。您可能会发现，为您编写的许多简单的 sql 往往是非常量身定制的，其中包含您懒得写的各种快捷方式，例如只返回绝对需要的数据。另一方面，如果您有一些自动化系统无法构建的极其复杂的查询和连接，那么您最好自己编写这些内容。

不过，总而言之，它们非常适合快速构建！

【讨论】：

【解决方案4】：

你不需要改变。如果 SqlConnection、SqlCommand 等对您有用，那就太好了。

对于我正在开发的数据库应用程序来说，它们工作得非常好，而且我有几十个并发用户没有任何问题。

【讨论】：

不确定你的观点。我得出的结论是，我可能会对我尚未使用的几乎任何新框架或技术感到内疚。所以我只是说可以使用稍微旧一点的框架。
呃，Joh W，我想 Meeh 是想告诉你，他会喜欢支持你，但这会破坏特殊数字 1337。
约翰，它是黑客 sp33k。我很想被困在那个号码上。 LEET hooah！

【解决方案5】：

直接使用 ADO.Net 并没有错，但是使用 ORM 可以节省您在开发和维护方面的时间。这是最大的好处。

【讨论】：

【解决方案6】：

需要考虑的一件事：未来的“新开发人员”是否会更倾向于了解或学习有据可查且被广泛采用的 OR/M 或您的自定义数据访问层？

对我来说，第一件事是时间。使用我最喜欢的 OR/M 的几分钟，nHibernate 与使用 ADO.NET 编写自定义数据访问层的几小时/几天。

我也喜欢 OR/M，因为维护声明性 XML 映射比维护潜在的数千行命令式代码要容易得多……或者更糟的是，在数千行存储过程代码之上维护数千行 C# 数据访问代码。在我当前的项目中，我在 58 个 XML 映射文件中映射了 58 个对象，每个文件少于 50 行。当我想到在 ADO.NET 中为 58 个实体编写/维护 CRUD 代码时，我感到畏缩。

我必须警告您阅读文档。许多，我敢说，与我共事过的人会喜欢像老鼠在奶酪上一样的工具，但他们永远不会阅读文档并学习技术。我建议在迁移到像 nHibernate 这样的新技术之前阅读文档。一杯好酒和一两个小时的事先认真阅读会带来好处。

【讨论】：

我确实看过 nHibernate，但不得不说，在我看来，我会花更多时间在 nHibernate 上，然后直接使用 ado.net。
我认为一旦你学会了使用 nHibernate 或 iBatis，它总是比编写 ADO.NET 更快。我在两面都写过，甚至为单个实体编写 CRUD，我用 nHibernate 花了几分钟（当我确切地知道该做什么时）与一个标准的小时或更长时间来编写 ADO.NET 代码（当我确切地知道要做什么时）做）——当然，可以使用像 CodeSmith 这样的工具来生成命令式。

【解决方案7】：

我在任何答案中都没有找到指向 ORM 的一般概念。 ORM 的总体思想是执行对象-关系映射并为您的业务类提供持久性。这意味着您将只考虑您的业务逻辑，并让 ORM 工具为您保存其状态。当然有很多不同的场景。正如已经说过的，使用纯 ADO.NET 并没有什么坏处，并且可能是您的应用程序（已经用这个 stile 编写的应用程序不会有任何好处），但是在新项目中使用 ORM 工具是一个非常好的主意。至于其他 - 我完全同意其他答案。

【讨论】：