linq - ORM(Linq、Hibernate...)真的那么有用吗？

Question

我一直在玩一些 LINQ ORM(LINQ 直接到 SQL)，我不得不承认我喜欢它的表达能力。对于类似实用程序的小型应用程序，它的运行速度也非常快:在某个表面上放置一个 SQL 服务器，然后您就可以使用 linq 了。

但是，对于较大的应用程序，DAL对我来说，设置或维护从来都不是什么大问题，而且通常情况下，一旦设置好，所有的编程都不会在那里发生......

老实说 - 我是 ORM 新手 - 问题:ORM 与手动编写体面的 DAL 相比有什么最大优势？

(似乎是双重的，但找不到)

更新:好的，它是双重的 :-) 我最终自己找到了它:

ORM vs Handcoded Data Access Layer

Answer 1

我在一个项目中使用了 JPA，起初我印象非常深刻。天哪，它节省了我所有编写 SQL 的时间!然而，渐渐地，我变得有些失望了。

难以定义没有代理键的表。有时我们需要没有代理键的表。有时我们想要一个多列主键。 TopLink 在这方面遇到了困难。

强制数据结构关系。 JPA 使用注解来描述字段与容器或引用类之间的关系。虽然这在第一个站点上看起来不错，但是当您在应用程序中以不同方式引用对象时，您会怎么做？例如，您只需要根据某些特定条件引用特定记录的特定对象(并且它需要高性能，没有不必要的对象分配或记录检索)。修改实体类的努力几乎总是超过如果您一开始从未使用过 JPA 所需要的努力(假设您完全成功地让 JPA 做您想做的事)。

缓存。 JPA 定义了对象缓存的概念。必须记住，数据库有自己的缓存，通常围绕最小化磁盘读取进行优化。现在您将数据缓存两次(忽略未收集的 GC 堆)。这怎么可能是一个优势超出了我的范围。

数据 != 对象。对于高性能应用程序，必须非常高效地从数据库中检索数据。强制创建对象并不总是一件好事。例如，有时您可能需要基元数组。对于直接使用 JDBC 的有经验的程序员来说，这大约需要 30 分钟的时间。

性能，调试。
在(次优的、自动生成的)缓存子系统中进行复杂的事情时，衡量应用程序的性能要困难得多，这进一步增加了项目资源和预算的压力。

大多数开发人员并不真正理解在将对象映射到表时一直存在的阻抗不匹配问题。这一事实确保 JPA 和 friend 在可预见的 future 可能会获得相当大的(咳嗽)成功。