ORM(Linq,Hibernate ......)真的有用吗？

Question

我一直在玩一些LINQ ORM(LINQ直接用于SQL),我不得不承认我喜欢它的表达能力.对于类似实用程序的小应用程序,它也可以非常快速地运行:在某些表面上删除SQL服务器并将其设置为linq.

然而,对于较大的应用程序,DAL对我来说从来不是一个很大的问题,设置,维护,而且通常一旦设置,所有的编程都不会发生在那里......

老实说 - 我是一个ORM新手 - 问题:ORM比手工编写体面的DAL有什么大的优势？

(看起来像一个双,虽然找不到)

更新:好吧它的双倍:-)我最终自己找到了:

ORM与手动编码数据访问层

Answer 1

• 强类型
• 无需自己编写DAL =>节省时间
• 无需自己编写SQL代码=>不易出错

Answer 2

我过去使用过Hibernate来动态创建非常复杂的查询.与构建适当的逻辑相比,创建适当的SQL所涉及的逻辑实现起来非常耗时Criteria.另外,Hibernate知道如何使用各种不同的数据库,因此我不需要在代码中添加任何逻辑.当然,我们必须针对不同的数据库进行测试,我需要编写一个扩展来适当地处理"喜欢"的查询,但是它会针对SQL Server,Oracle和HSqldb(用于测试)运行而没有任何问题.

还有一个事实是你不需要编写更多的代码,这总是一件好事:)我不能说我在任何大的事情上都使用过LINQ to SQL,但是我用它来做一个"快速而肮脏的"网站(非常小,很少更新,从全层抽象中获得的好处)很可爱.

Answer 3

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

1. 难以定义没有代理键的表。有时我们需要没有代理键的表。有时我们需要一个多列主键。TopLink 在这方面遇到了困难。
2. 强制数据结构关系。JPA 使用注释来描述字段与容器或引用类之间的关系。虽然这乍一看似乎很棒，但是当您在应用程序中以不同方式引用对象时，您会怎么做？例如，您只需要根据某些特定条件引用特定记录的特定对象（并且它需要高性能，没有不必要的对象分配或记录检索）。修改实体类的工作量几乎总是会超过您从一开始就没有使用过 JPA 的工作量（假设您完全成功地让 JPA 完成您想要的操作）。
3. 缓存。JPA 定义了对象缓存的概念。必须记住，数据库有自己的缓存，通常围绕最小化磁盘读取进行优化。现在您将数据缓存两次（忽略未收集的 GC 堆）。我无法理解这如何成为一个优势。
4. 数据！=对象。对于高性能应用程序，必须非常高效地从数据库检索数据。强制创建对象并不总是一件好事。例如，有时您可能需要基元数组。对于直接使用 JDBC 的经验丰富的程序员来说，这大约需要 30 分钟的时间。
5. 性能、调试。在（次优、自动生成的）缓存子系统中发生复杂的事情时，衡量应用程序的性能要困难得多，这进一步加剧了项目资源和预算的紧张。

大多数开发人员并不真正理解将对象映射到表时始终存在的阻抗不匹配问题。这一事实确保了 JPA 和他的朋友们在可预见的未来可能会取得相当大的成功（咳咳）。