ORM（Linq，Hibernate ......）真的有用吗？

Question

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

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

我的，诚实 - 我是一个ORM新手 - 问题：ORM在手工编写体面的DAL方面有什么大的优势？

（似乎是双重的，虽然找不到它）

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

ORM vs Handcoded Data Access Layer

Answer 1

• 强类型
• 无需自己编写DAL =＆gt;节省时间
• 无需自己编写SQL代码=＆gt; 不太容易出错

Answer 2

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

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

Answer 3

嗯，对我而言，每次我需要实现新的域模型时，不必重新发明/重新创建轮子。使用例如nHibernate（我选择的ORM）来创建，使用和维护数据访问层要简单得多。

你没有具体说明你如何构建你的DAL，但对我来说，我曾经花了很多时间一遍又一遍地做同样的事情。我曾经从数据库模型开始，从那里开始工作，创建存储过程等。即使我有时使用很少的工具来生成部分设置，也是很多重复编码。

现在我从域名开始。我用UML对它进行建模，大多数时候我能够从该模型生成所有内容，包括数据库模式。它需要在这里和那里进行一些调整，但是根据我目前的设置，我可以立即完成95％的数据访问工作。我保存的时间可以用来微调需要调整的部分。我很少需要编写任何SQL语句。

那是我的两分钱。 ： - ）

Answer 4

我在一个项目中使用了JPA，起初我印象非常深刻。天哪，它一直在节省我写SQL的时间！然而，渐渐地，我变得有点幻想。

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

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

Answer 5

不同数据库供应商之间的可移植性。

Answer 6

  

我的，诚实 - 我是一个ORM新手 - 问题：ORM在手工编写体面的DAL方面取得了哪些进展？

并非所有程序员都愿意甚至能够写出“体面的DAL”。那些不能或只是想到它的人，发现LINQ或任何其他ORM是一种祝福。

由于其表现力，我个人使用LINQ来操作代码中的集合。它提供了一种非常紧凑和透明的方式，可以直接在代码中对集合执行一些常见任务。

当您想要手动创建非常具体和优化的查询时，LINQ将不再对您有用。然后，您可能会混合使用与自定义存储过程相连的LINQ查询。由于这些考虑，我决定在我当前的项目中使用LINQ to SQL（因为我有一个像样的（imho）DAL层）。但我确信LINW会为简单的网站做得很好，比如你的博客（或者说SO）。

使用LINQ / ORM时，可能还会考虑高流量站点的滞后（因为每个传入的查询都必须重新编译）。虽然我不得不承认我没有在SO上看到任何性能问题。

您还可以考虑等待Entity Framework v2。它应该比LINQ更强大（希望不如v1那么糟糕（根据一些人的说法））。

Answer 7

透明持久性 - 无需调用Save()即可保存（并级联）更改。乍一看，这似乎是一场噩梦，但是一旦你习惯了它而不是反对它，你的域代码几乎可以完全消除持久性问题。我不知道除了Hibernate / NHibernate之外的任何ORM都可以做到这一点，尽管可能会有一些......

Answer 8

回答这个问题的最好方法是准确理解像Hibernate这样的库实际上是代表你完成的。大多数时候抽象存在是有原因的，通常是为了使某些问题不那么复杂，或者在Hibernate几乎是DSL的情况下，以简单简洁的方式表达某些持久性概念。

• 通过更改注释而不是编写大量代码，可以轻松更改集合的获取策略。

• Hibernate和Linq经过许多人的验证和测试，没有多少工作就没有机会达到这种质量。

• Hibernate解决了许多需要花费数月和数年才能编写代码的功能。

Answer 9

此外，虽然JPA文档说支持复合键，但它很快就会非常（非常）棘手。你可以轻松地花几个小时（几天？）试图让一些非常简单的工作。如果JPA真的让事情变得更简单，那么开发人员应该不再考虑这些细节。它没有，我们不得不理解两个抽象层次，即ORM（JPA）和JDBC。对于我当前的项目，我使用的是一个非常简单的实现，它使用一个包受保护的静态get“构造函数”，它接受一个ResultSet并返回一个Object。这是每个类大约4行代码，每个字段加一行代码。它简单，高性能，而且非常有效，而且我保持完全控制。如果我需要以不同方式访问对象，我可以添加另一个读取不同字段的方法（例如，将其他字段保留为空）。我不需要一个告诉我“ORM必须如何（！）完成”的规范。如果我需要为该类进行缓存，我可以根据需要进行精确实现。

Answer 10

我使用过Linq，我发现它非常有用。我节省了大量的时间来编写数据访问代码。但是对于大型应用程序，您需要的不仅仅是DAL，对于它们，您可以轻松扩展由它创建的类。相信我，它确实提高了你的生产力。