使用OR-Mapper有意义吗？

Question

使用OR-Mapper有意义吗？

我在Stack Overflow上提出这个问题，因为这是我知道的最好的地方，可以找到愿意给予帮助和建议的聪明开发者。

我的推理如下：

1.) SQL应该放在哪里？

a.) 在我参与过的每个专业项目中，数据安全性是一个关键要求。存储过程提供了一个自然的通道，用于控制访问和审计。

b.) 生产中的应用程序问题通常可以在表格和存储过程之间解决，而无需发布新版本。

2.) 我如何控制生成的SQL？我信任解析树来生成高效的SQL。我对在SQL Server和Oracle中优化SQL有很多经验，但如果我再也不必这样做，我也不会感到失望。 :)

3.) 如果我从存储过程获取数据，使用OR-Mapper有什么意义？

我使用了存储库模式和自己开发的通用数据访问层。如果需要缓存集合，我就会缓存它。我还有使用EF进行小型CRUD应用程序和帮助调优NHibernate应用程序的经验。所以我有点偏见，但愿意学习。

在过去的几年中，我们听到了很多值得尊敬的开发人员倡导使用特定的ORM（Entity-Framework、NHibernate等...）。

有人能告诉我，为什么在主流开发的大型项目中应该使用ORM？

编辑：http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html 似乎对这个话题进行了深入的讨论，但是已经过时了。

另一个编辑： 每个人似乎都同意存储过程应该用于重型企业应用程序，因为它们的性能优势和将编程逻辑添加到数据附近的能力。

我看到支持OR Mapper最强烈的论点是开发人员的生产力。

我怀疑ORM运动的一个主要推动因素是开发人员偏好保持持久性不可知（除缓存之外，不关心数据是在内存中还是在数据库中）。

ORM似乎是本地和小型Web应用程序的出色时间节省工具。

也许我看到的最好的建议来自client09：使用ORM设置，但在数据库密集型任务（即当ORM似乎不足时）中使用存储过程。

- RBZ

---

CSLA不是一个OR-Mapper。这是一个常见的误解。 - Todd Stout

也许这对你来说更加实时。https://dev59.com/zHRC5IYBdhLWcg3wG9Xp - dkretz

Answer 1

我曾经是一名专业的SP（存储过程）开发人员，认为这是数据库开发唯一正确的方式，但在过去的3-4个项目中，我使用EF4.0完成了开发，没有使用SP，我的生产力有了惊人的提升 - 现在我可以用几行代码完成以前需要一天才能完成的任务。

我仍然认为，在某些情况下，SP非常重要（选择合适的SP可以显著提高性能），但对于一般的CRUD操作，我无法想象回到以前的做法。

所以对我来说，使用ORM的原因是开发人员的生产力 - 无论如何，一旦你克服了学习曲线。

- E.J. Brennan

Answer 2

一种不同的方法... 随着No SQL运动的兴起，您可能想尝试使用对象/文档数据库来存储数据。这样，您基本上将避免OR Mapping所带来的困境。将数据存储为应用程序使用它们，并在工作进程中进行转换，将其移动到更多关系型/OLAP格式以供进一步分析和报告。

- Jimmy Chandra

Answer 3

存储过程非常适合将数据库逻辑封装在一个地方。我曾经参与一个只使用Oracle存储过程的项目，目前正在进行一个使用Hibernate的项目。我们发现很容易开发出冗余的存储过程，因为我们的Java开发人员不熟悉PL / SQL包依赖关系。

作为该项目的DBA，我发现Java开发人员更喜欢将所有东西都放在Java代码中。你会遇到偶尔的，“为什么我不能只通过返回的所有对象循环？”这引起了许多“为什么索引没有解决这个问题？”问题。

使用Hibernate，您的实体不仅可以包含它们连接的数据库属性，还可以包含对它们执行的任何操作。

例如，我们有一个任务实体。可以添加或修改任务等其他操作。这可以在命名查询中的Hibernate实体中建模。

因此，我会建议使用ORM设置，但对于数据库密集型操作，请使用存储过程。

将SQL保留在Java中的缺点是您面临着开发人员使用非参数化查询的风险，从而使您的应用程序容易受到SQL注入攻击。

- dseibert

---

使用Hibernate，您的实体不仅可以包含它们链接的数据库属性，还可以包含对它们执行的任何操作。但是我也可以在没有ORM的情况下实现这一点。此外，单一职责在这里也必须发挥作用。那么DTO的角色是什么：传输数据还是基于值进行计算？ - RBZ

Answer 4

以下只是我的个人意见，因此比较主观。

1.) 我认为需要区分本地应用程序和企业应用程序。对于本地和一些 Web 应用程序，直接访问数据库是可以的。对于企业应用程序，我觉得更好的封装和权限管理使存储过程最终成为更好的选择。

2.) 这是 ORM 的一个大问题之一。它们通常针对特定的查询模式进行优化，只要使用这些模式，生成的 SQL 通常质量很好。然而，对于需要在数据附近执行的复杂操作来保持高效性的情况，我觉得使用手动 SQL 代码仍然是最好的方式，在这种情况下，代码进入 SP。

3.) 与直接访问“松散”数据集（即使这些数据集是有类型的）相比，处理对象作为数据实体也很有益。将结果集反序列化为对象图非常有用，无论结果集是由 SP 返回还是从动态 SQL 查询返回的。

如果您正在使用SQL Server，我邀请您查看我的开源bsn ModuleStore项目，它是一个用于数据库模式版本控制的框架，并通过一些轻量级ORM概念（在调用SP时进行对象序列化和反序列化）来使用SP。

- Lucero