4

What do you suggest for Data Access layer? Using ORMs like Entity Framework and Hibernate OR Code Generators like Subsonic, .netTiers, T4, etc.?

4

5 回答 5

8

对我来说，这很容易，您生成代码。

我将在这里稍微偏离主题，因为有一个更大的潜在谬误在起作用。谬误在于这些 ORM 框架解决了对象/关系阻抗不匹配问题。这种说法是赤裸裸的谎言。

我发现解决对象/关系阻抗不匹配的最佳方法是专门使用 OOP 并使用对象数据库，或者专门使用关系数据库的习语而忽略 OOP。

“一切都是表”的抽象对我来说，比“一切都是类”的抽象要强大得多。当您编码到数据库而不是对象模型时，它需要更少的代码、更少的智力工作并导致更快的代码。

对我来说，这似乎很明显。如果您的应用程序是数据驱动的，那么您的代码肯定也应该是数据驱动的吗？然而，要说这是非常有争议的。

这里的核心问题是，当与数据库结合使用时，OOP 变成了一个真正有漏洞的抽象。当您看到代码在数据库中生成的流量时，按照 OOP 的习惯用法编写时看起来非常合理的代码看起来完全是疯狂的。当这种混乱成为性能问题时，OOP 是第一个牺牲品。

真的没有办法解决这个问题。数据库处理数据集。OOP 专注于类的实例。试图让两人结婚，总是以离婚收场。

所以要回答你的问题，我相信你应该生成你的类并尝试让它们尽可能地映射底层数据库结构。

于 2008-11-02T11:48:13.587 回答
3

也许有争议的是，我一直认为使用 ADO.NET 管道的代码生成器从根本上解决了错误的问题。

在某个时候，希望在学习了连接字符串、SqlCommands、DataAdapters 和所有这些之后不久，我们会注意到：

  1. 这样的代码很难看
  2. 写的很无聊
  3. 如果你用手做，很容易错过一些东西
  4. 每次要访问数据库时都必须重复

那么，要解决的问题是“如何快速多次做同一件事”？

我拒绝。

使用代码生成器来加快这个过程仍然意味着您在整个业务类（或数据访问层，如果您将其与业务逻辑分开）中都有大量代码。

然后，如果您想做一些通用的事情（例如跟踪存储过程的使用），如果代码生成器还没有您想要的功能，您最终不得不自定义代码生成器。即使它确实如此，你仍然必须一直重新生成所有内容。

我喜欢做一件事，而不是很多次，不管我能做多快。

所以我推出了自己的数据访问类，它知道如何添加参数、设置和关闭连接、管理事务和其他很酷的东西。它只需要编写一次，并且从需要完成一些数据库工作的业务对象调用它的方法由一行代码组成。

当我需要使应用程序支持多线程数据库访问时，只需要更改数据访问类，所有业务类都只做它们已经做的事情。

于 2008-11-02T10:42:50.613 回答
1

没有正确的答案，这完全取决于您的项目。正如 Simon 指出的那样，如果您的应用程序都是数据驱动的，那么根据域的大小和复杂性，使用非 oop 范式可能是有意义的。我在使用事务脚本模式构建系统方面取得了很大成功，该模式在系统中传递 XML 消息。

然而，随着应用程序规模和复杂性的增长（5 或 6 个 Web、多个 Web 服务、大量的 COM+ 组件、遗留和 .net 代码、8 个以上的数据库和 800 多个表 4,000+程序）。没有人知道什么是什么，复制猖獗。

除了OOP，还有其他方法可以减轻维护；但是，如果您有一个非常复杂的域，那么拥有一个丰富的域模型是理想的恕我直言，因为它允许业务规则以很好的封装组件表示。

要回答您的问题，请尽可能避免使用代码生成器。代码生成器是灾难的根源，但如果您确实使用代码生成器，请不要修改生成的代码。还要确保有一个良好的流程，以便开发人员轻松获取新生成的代码。

我建议使用以下任一：ORM 或手卷轻量级 DAL。我目前正在将一个项目从我的手卷 DAL 转移到 nHibernate，并且取得了很大的成功；但是，我喜欢使用任一选项。此外，如果您正确地将您的关注点（数据访问从业务层与表示）分开，您可以拥有一个可能与 Dao（数据访问对象）对话的单个服务层，对于一个对象是 ORM，而对于另一个对象是手动滚动的）。我喜欢这种灵活性，因为它允许将最好的工具应用到工作中。

我喜欢 nHibernate 而不是手卷 DAL，因为虽然我的 DAL 确实抽象了大部分 ADO.Net 代码，但您仍然必须编写将数据读取器带到对象或对象并创建参数的代码。

于 2008-11-09T02:20:47.567 回答
0

我一直更喜欢使用代码生成器路线，尤其是在 C# 中，您可以利用扩展类向基本数据对象添加功能。

于 2008-11-02T10:17:41.693 回答
0

讨厌这么说，但这取决于。如果您找到适合您需求的 ORM 工具，请选择它。我们在开发应用程序时分小步编写了自己的系统。我们正在使用 C++，而且无论如何都没有那么多工具。我们最终成为数据库的 XML 描述，从中生成 SQL 生成脚本和基本对象层和元数据。

做好功课并评估这些工具，您会找到适合您需求的工具。

于 2008-11-02T10:23:19.047 回答