ORM 还是直接 SQL？ [复制]答案

【问题标题】：ORM or straight SQL? [duplicate]ORM 还是直接 SQL？ [复制]
【发布时间】：2025-12-05 01:45:01
【问题描述】：

可能重复：
Using an ORM or plain SQL?

您会选择使用 ORM 还是某种家庭纺 DAL？为什么？

ORM 的优势似乎很明显——更好的结构/组织、更好的语言适配等。但我担心性能问题。谁有战争故事要分享？任何关于不那么明显的风险或回报的见解将不胜感激。

【问题讨论】：

【解决方案1】：

出于您提到的原因，我会使用 ORM。

它们通常表现良好。如果在某个领域存在性能问题，您可以稍后再优化该部分，或者如果确实有帮助，则切换到直接 SQL，因为这两种技术并不相互排斥。

【讨论】：

【解决方案2】：

我只是将其作为我个人的意见，因为这是一个有点神圣的话题。

每次我开始一个项目并尝试一个 ORM（无论是 L2SQL、Subsonic、EF NHibernate 等）时，我总是最终将其废弃并使用存储过程手动重写 DAL。

ORM 对于快速搭建很方便，但是如果您正确设计实体层，插入新的数据访问层非常简单，而且我遇到了太多问题，要么与 ORM 抗争，要么做我想做的事, 或者 ORM 只是简单地做一些愚蠢的事情（N+1 查询，或者当我真的只需要主键查找时拉下相关表等）。

【讨论】：

【解决方案3】：

我会（并且确实）选择使用 ORM，并了解它如何工作得足够好，以尽可能多地发挥性能。

例如；大多数 ORM 允许您使用大量存储过程/服务器函数，因此您可以在可能的最佳位置运行高度优化的代码。但你必须知道如何/何时这样做。

您还可以使用一些隐藏在 ORM 表面之下的技术。例如，编译 LINQ to SQL 查询。

我认为很多时候，滚动自己的 DAL 最终在性能方面并没有任何更好的表现，只是因为尝试重新创建大量样板代码。

【讨论】：

【解决方案4】：

我会说使用 ORM。一开始我有点反对他们，因为对于简单的项目来说，直接编写 SQL 很容易，我没有看到额外的好处。但是随着项目的增长，查询变得更加复杂。尤其是像hierarchies...这样的东西，如果你的 ORM 支持这些东西，它真的可以节省很多时间。

如果你担心性能问题，等到它开始出现问题，然后检查你的 ORM 生成的 SQL 并使用它的 raw_sql 函数来更有效地重写它，或者使用其他辅助方法来哄它正确的方向。

【讨论】：

【解决方案5】：

这实际上取决于应用程序的很大一部分以及它要扩展多少，而且如果您担心性能，那么您在编程语言方面也会遇到同样的困境，恕我直言 ORM 非常适合您已经说过的原因，但是它们（如一切）都有边界，其中大部分是性能，你最终将不得不处理查询，你称它们为 SQL 或 HQL 或 ANY_OTHER_SUFF_QL，

如果您选择 ORM，我的建议是尝试利用它的所有功能，许多项目最终使用 ORM，只使用 SAVE UPDATE DELETE 而不使用层次结构模式或缓存改进

【讨论】：

【解决方案6】：

如果任何一种选择都能满足任何业务需求，我会感到惊讶。我也怀疑有很多缺陷可以直接归因于任何一种选择。

就我个人而言，我发现将数据输入和输出数据源非常容易，而且我通常不会花费大量时间，但这可能只是我自己。

我想说，除非你对其中一个有强烈的偏好，否则它可能并不重要。

【讨论】：

【解决方案7】：

我认为这取决于您正在从事什么样的项目。如果您正在使用一些 OO 语言进行编程，那么使用 ORM 可能是一个好主意。但是如果你的项目比较底层，或者你真的很担心性能（我相信设计好的ORM不会给你带来不好的性能），那么直接sql可能是最好的选择。

【讨论】：