使用 OR-Mapper 有意义吗？答案

【问题标题】：Does it make sense to use an OR-Mapper?使用 OR-Mapper 有意义吗？
【发布时间】：2011-03-17 18:42:12
【问题描述】：

使用 OR-mapper 有意义吗？

我将那里的这个问题放在堆栈溢出上，因为这是我所知道的最好的地方，可以找到愿意提供帮助和意见的聪明的开发人员。

我的推理如下：

1.) SQL 属于哪里？

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

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

2.) 如何控制生成的 SQL？我相信解析树可以生成高效的 SQL。我有相当多的在 SQL-Server 和 Oracle 中优化 SQL 的经验，但如果我不必再做一次，我不会感到受骗。 :)

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

我使用了带有本地通用数据访问层的存储库模式。如果需要缓存一个集合，我会缓存它。我也有在小型 CRUD 应用程序上使用 EF 的经验，以及帮助调整遇到性能问题的 NHibernate 应用程序的经验。所以我有点偏见，但愿意学习。

在过去的几年里，我们都听到了很多受人尊敬的开发人员提倡使用特定的 OR-Mapper（实体框架、NHibernate 等）。

谁能告诉我为什么有人应该迁移到 ORM 来进行大型项目的主流开发？

另一个编辑：似乎每个人都同意将存储过程用于重型企业应用程序，因为它们具有性能优势以及能够将编程逻辑添加到更接近数据的位置。

我发现支持 OR 映射器的最有力论据是开发人员的生产力。

我怀疑 ORM 运动的一大动机是开发人员倾向于保持与持久性无关（不管数据是在内存中 [除非缓存] 还是在数据库中）。

对于本地和小型 Web 应用程序，ORM 似乎非常节省时间。

也许我看到的最好的建议是来自 client09：使用 ORM 设置，但对数据库密集型的东西使用存储过程（当 ORM 似乎不足时也称为存储过程）。

【问题讨论】：

【解决方案1】：

多年来，我一直是专业的 SP，并认为这是进行 DB 开发的唯一正确方法，但我最近完成的 3-4 个项目是在没有 SP 的情况下在 EF4.0 中完成的，并且在我的工作效率确实令人惊叹——我现在可以用几行代码完成之前一天需要花费的事情。

我仍然认为 SP 对于某些事情很重要，（有时您可以通过精心挑选的 SP 显着提高性能），但对于一般的 CRUD 操作，我无法想象再回头。

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

【讨论】：

【解决方案2】：

一种不同的方法...随着现在无 SQL 运动的兴起，您可能想尝试使用对象/文档数据库来存储您的数据。通过这种方式，您基本上将避免 OR Mapping 的地狱。在您的应用程序使用数据时存储数据，并在工作进程中在后台进行转换，以将其转换为更具关系性/OLAP 格式，以便进一步分析和报告。

【讨论】：

【解决方案3】：

存储过程非常适合将数据库逻辑封装在一个地方。我从事过一个仅使用 Oracle 存储过程的项目，目前正在从事一个使用 Hibernate 的项目。我们发现开发冗余过程非常容易，因为我们的 Java 开发人员并不精通 PL/SQL 包依赖关系。

作为项目的 DBA，我发现 Java 开发人员更喜欢将所有内容都保存在 Java 代码中。你偶尔会遇到，“我为什么不循环遍历刚刚返回的所有对象？”这引起了一些“为什么索引不处理这个？”问题。

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

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

所以我会说使用 ORM 设置，但对数据库密集型的东西使用过程。

将 SQL 保留在 Java 中的一个缺点是，您可能会冒开发人员使用非参数化查询使您的应用程序面临 SQL 注入的风险。

【讨论】：

回应：“使用 Hibernate，您的实体不仅可以包含其链接的数据库属性，还可以包含对其采取的任何操作。”但我可以在没有 ORM 的情况下得到这个。此外，单一职责也必须在这里发挥作用。 Dto 的作用是什么：传输数据还是根据值进行计算？

【解决方案4】：

以下只是我个人的看法，比较主观。

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

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

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

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

【讨论】：