ORM还是直接SQL？

Question

  

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

您会选择使用ORM或某种家庭旋转DAL吗？为什么？

ORM的优势显而易见 - 更好的结构/组织，更好的语言适应性等。但我担心性能问题。有人分享战争故事吗？任何关于不那么明显的风险或回报的见解都会非常感激。

Answer 1

我完全按你提到的原因使用ORM。

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

Answer 2

我将把这个留作我个人的意见，因为这是一个神圣的话题。

每次我开始一个项目并尝试ORM（无论是L2SQL，Subsonic，EF NHibernate等），我总是最终将其废弃为某些点并使用sprocs手工重写DAL。

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

Answer 3

我会（并且确实）选择使用ORM，并了解它如何运作得足够好以尽可能地挤出它。

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

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

我认为很多时候滚动的人拥有DAL可能最终没有更好的性能，只是因为一个人试图重新创建大量的样板代码。

Answer 4

我会说使用ORM。起初我有点反对他们，因为直接编写SQL对于简单项目来说非常简单，我没有看到额外的好处。但随着项目的增长，查询变得更加复杂。特别是像hierarchies之类的东西......如果你的ORM支持那些类型的东西，它确实可以节省大量的时间。

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

Answer 5

这取决于应用程序的大部分内容以及它的扩展程度，如果你担心性能，那么你对编程语言也有同样的困境，恕我直言你真的非常适合你已经说过的但是他们（如同所有的一切都有bounderies，其中大多数是性能的，你最终将不得不处理Query wethr你称之为SQL或HQL或ANY_OTHER_SUTFF_QL，

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

Answer 6

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

就我个人而言，我发现很容易将数据输入和输出数据源，而且通常不是我花了很多时间，但那可能只是我。

我会说，除非你对一个或另一个有强烈的偏好，否则它可能无关紧要。

Answer 7

我认为这取决于你正在做什么样的项目。如果您使用某种OO语言编程，那么使用ORM可能是个好主意。但是如果你的项目更低级，或者你真的担心性能（我相信一个好的设计ORM不会给你糟糕的性能）那么直接sql可能是最好的选择。