ORM：是或否？

Question

我必须用Java开始一个中型项目，但我不是一般的ORM的粉丝所以问题是：我是否应该考虑ORM设计项目（供以后使用）？

RDBMS是Oracle 10g，查询将非常耦合到Oracle语法/函数（即文本，挖掘，CONNECT BY等）。

非常感谢。

Answer 1

您可能希望查看之前讨论ORM优势的问题：What are the advantages of using an ORM?

最相关的部分（取自已接受的答案）：

  

如果你有复杂的，手动调整的SQL，   使用一个没什么意义   ORM。

如果你不断地通过ORM并编写自己的SQL，那么ORM可能最终会妨碍你。

Answer 2

因为我不允许评论你的帖子Ill评论（缺少积分）。

对于你不喜欢ORM的讨论会有好处。

Imo，我会去的。如果你由于某种原因找到一个ORM缓慢的查询，那么我会自己做。仅仅因为你使用ORM大多数任务并不意味着你必须使用它。但是，是的，这将是首选。

Answer 3

我个人已经发现它们（好吧，Hibernate）是一个令人难以置信的时间下沉。我花了太多时间试图找出它实际上在幕后做了什么，而不是节省时间。正如其他人所提到的，如果您的数据模型增长超过一定的复杂性，那么在您和数据库之间建立另一层就会产生更多的摩擦。如果您的数据模型并不复杂，那么您无论如何都不需要ORM。

我做建议使用某种抽象来使SQL远离Java代码，但这可以通过DAO层和属性文件或其他方式完成。此外，像IBATIS或Spring JDBC这样的工具也很有帮助，因为您仍然可以编写自己的查询，并且只需使用框架来帮助处理JDBC和Model对象之间的数据混乱的所有样板代码。

PS：有趣的旁注。在我的办公室，我们实际上有一张Gavin King的框架图片，我们都在诅咒肖像。 “嘿，这是你的转向处理今天的Hibernate问题，所以这是Gavin。” ： - ）

Answer 4

ORM的另一个优点是它在您的简历上看起来非常好。今天广告的大多数工作（至少是Java开发人员）需要一些ORM知识。所以如果你有机会参与一个项目，我会选择Spring和Hibernate，因为它会真正提升你的简历。

我认为与其他问题的关联很好地涵盖了技术优势所以我不会对它们说些什么。

Answer 5

我个人更喜欢尽可能接近SQL，所以我会使用iBatis，JOOQ或MentaBean。顺便提一下，MentaBean提供了一种尽可能接近SQL的方法，同时为样板JDBC代码提供了很多帮助。

Answer 6

ORM故意将工作对象与数据库分离，创建抽象（不可避免地存在泄漏）。因此，您最终会通过隧道恢复以恢复您故意消除的内容。

如果您的应用程序中有很多是故意在数据库中实现的，那么ORM只会给您的信号增加噪音 - 并会衰减信号。

Answer 7

这取决于......

并且您不必为每个数据库访问使用ORM ...

Answer 8

是。 ORM可以减轻app开发人员的负担;至少，考虑到它们的设计不应该给设计增加太多负担，如果您决定使用ORM，将来可能会有很大的帮助。

Answer 9

像其他人提到的那样;如果你是依赖于DB（关系）的，那么ORM就会给你提供一些不那么有用的抽象。 但最重要的是：您（想）是否将数据作为对象处理？如果是，ORM就是为此而设计的。如果没有，为什么这么麻烦。 如果需要的话你可以在以后添加ORM - 可能比前期花费更多的时间，但反过来（在它阻塞之后淘汰Hibernate）会更糟糕。

但ORM之间也存在差异;例如，iBatis可能比Hibernate更合适（对于这个特定主题还有其他问题）。

Answer 10

OR映射确实可能是特定于数据库的SQL的问题。但是，OR映射的一些概念非常强大，可以更容易地与数据库进行交互。许多OR映射器常见的一些概念是：

• 数据库架构的代码生成。
• 类型安全（某些ORM）
• 比JDBC提供的更强大的变量绑定
• 对象的SQL组合以避免SQL语法错误

您的任务的一个好工具可能是https://www.jooq.org，它允许您创建所需的任何SQL（包括嵌套选择，联合，复杂连接，别名，存储过程，UDT等）。

免责声明：我为供应商工作

Answer 11

ORM： 对于任何类似软件的企业都是如此，数据很复杂......多层次，多表，多层......但即使在这里，也建议将NHibernate和EF6以及数据库视图混合在一起。

不适用于任何特殊应用。像测量一样，你需要在哪里保存很多数据，但没有数据复杂性

使用ORM有多种可能性，一切都取决于你想要的。

作为一个真正的ORM映射器，我强烈推荐 NHibernate 和 Fluent NH 映射。你需要进行大量的研究才能将一个漂亮的架构组合在一起，但是没有什么能阻挡你。只需极少的妥协，您就可以获得真正的灵活性。

EF6x （核心不是prod.-ready IMHO）被称为ORM，但它产生的更接近DAL。有些东西是你用EF6无法有效做的。尽管如此，这是我最喜欢的阅读模型工具，而我将它与NHibernate（NH我用于DDD /写模型）结合起来。

现在表现 - 它总是有利可图。如果您深入了解ORM 架构（请参阅我的文章：avoid ORM bad habits），那么您将直观地找到使其更快的方法。这是我关于如何使EF6x 5x 更快的另一篇文章（至少在阅读情况下）：EF6.x 5x faster