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

Question

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

更新

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

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

然而，在我看来这是过度杀戮的方法。为什么我要创建映射文件？即使我创建一个映射文件并让我的表更改，那么我的代码将不再工作。但是，如果我使用ado.net返回一个简单的数据表，那么我的代码仍然有用。我在这里错过了什么？

Answer 1

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

您可能只需要做更多的手动工作。如果你是从具有SqlCommand和SqlDataReader的表中选择您的前10位客户，您需要对结果进行迭代，提取每一项数据（如客户编号，客户名称等），并且您正在处理与数据库结构密切相关，例如行和列。这对某些情况来说很好，但在其他情况下工作太多了。

ORM给你的是很多为你处理的“笨拙的工作”。您只需告诉它获取前十大客户的列表 - 作为“客户”对象。 ORM将关闭并获取数据（最有可能使用SqlCommand，SqlDataReader），然后提取零碎，并为您组装好的，易于使用的“客户”对象，这些对象更容易使用，因为它们是您的代码处理的 - 客户对象。

所以使用ADO.NET绝对没有问题，如果你知道它是如何工作的话，这是一件好事 - 但是ORM可以为你节省大量繁琐，重复和乏味的工作，让你专注于你真正的业务问题在对象层面。

马克

Answer 2

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

其次，ORM是一种在某种程度上“标准化”DAL的好方法，可以提高不同项目的灵活性。

最后，通过良好的ORM，您可能更容易用替换您的底层数据源，因为一个好的ORM将有许多不同的方言。当然，这只是一个副作用：）

Answer 3

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

至于表现，这可以是两种方式。您可能会发现很多为您编写的简单sql通常都是使用各种快捷方式量身定制的，这些快捷方式您可能懒得编写，例如只返回绝对必需的数据。另一方面，如果你有一些非常复杂的查询和连接，自动化系统无法构建，那么你最好自己保留这些。

总而言之，它们对于快速构建来说非常棒！

Answer 4

您无需更改。如果SqlConnection，SqlCommand等适合您，那就太棒了。

对于我正在开发的数据库应用程序，它们只能很好地工作，并且我有几十个并发用户没有问题。

Answer 5

有一点需要考虑：未来的“新开发者”是否会更倾向于了解或学习记录良好且广泛采用的OR / M或您的自定义数据访问层？

对我而言，最重要的是时间。使用我最喜欢的OR / M，nHibernate与使用ADO.NET编写自定义数据访问层的小时/天相隔几分钟。

我也赞成OR / Ms，因为维护声明性XML映射比维护数千行命令代码更容易......或者在数千行存储过程代码之上更糟糕的数千行C＃数据访问代码。在我当前的项目中，我有58个对象映射在58个XML映射文件中，每个文件少于50行。当我考虑在ADO.NET中为58个实体编写/维护CRUD代码时，我感到畏缩。

我必须提醒您阅读文档。很多人，我敢说最多，和我一起工作的人会跳上像奶酪上的小鼠一样的工具，但他们永远不会阅读文档并学习技术。我建议在转向nHibernate等新技术之前阅读文档。一个好的杯子和一两个小时的硬阅读将带来好处。

Answer 6

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

Answer 7

直接使用ADO.Net没有任何问题，但使用ORM可以节省开发和维护时间。这是最大的好处。