您如何看待不是真正的ORM的新Java持久性工具？[关闭]

Java的持久性

在过去的几年中，我使用EJB 2.0，Hibernate，JPA和自家的概念，在Java持久性抽象领域积累了经验。在我看来，他们的学习曲线陡峭且复杂。另外，作为SQL的忠实拥护者，我还认为许多抽象模型都提供了过多的SQL抽象，从而创建了诸如“标准”，“谓词”，“限制”之类的概念，这些概念是非常好的概念，但对SQL却不是。

Java中的持久性抽象的一般思想似乎是基于对象关系模型的，其中RDBMS以某种方式与OO世界相匹配。ORM辩论一直以来都是一种激动人心的辩论，因为似乎没有一个适合所有人的解决方案-甚至可以存在这样一种解决方案。

OO

我个人对避免ORM相关问题的偏爱是坚持关系世界。现在，数据模型范式的选择不应成为讨论的话题，因为它是个人喜好，或者是哪种数据模型最适合具体问题。我想开始的讨论围绕着我自己的持久性工具jOOQ进行。我设计了jOOQ，以提供现代持久性工具具有的大多数优势：

• 基于SQL的领域特定语言
• 源代码生成将基础数据库模式映射到Java
• 支持许多RDBMS

添加一些现代持久性工具所没有的功能（如果我错了，请纠正我）：

• 支持复杂的SQL-联合，嵌套选择，自联接，别名，case子句，算术表达式
• 支持非标准SQL-存储过程，UDT，ENUMS，本机函数，分析函数

请查看文档页面以获取更多详细信息：http : //www.jooq.org/learn.php。您将看到在Linq中为C＃实现了非常相似的方法，尽管Linq并非专门为SQL设计的。

问题

现在，说了我是SQL的忠实拥护者，我想知道是否其他开发人员也会分享我对jOOQ（或Linq）的热情。这种持久性抽象方法是否可行？您可能会看到哪些优点/缺点？我如何改善jOOQ，您认为有什么缺失？从概念上或实践上我哪里出了问题？

批判但建设性的答案表示赞赏

我知道这场辩论是一场感性的辩论。有许多很棒的工具已经在做类似的事情。根据您自己的经验或您可能已阅读的文章，我感兴趣的是至关重要但具有建设性的反馈。

我认为您走在正确的道路上，应该继续您的解决方案。先前的一些批评过于苛刻，但提出了一些合理的观点。

我也一直在努力寻找适合我需求的功能完备的ORM解决方案，但是我看过的每个解决方案都没有找到。每个人都有其优点和缺点，但没有一个人真正做到了我想要的一切。我同意您对这些解决方案的批评-即它们通常很复杂并且学习曲线很陡。

最高竞争者必须是事实上的标准Hibernate。它功能齐全，功能强大且经过了良好的测试。我尊重它，并对其表示赞赏。现在，冒着冒犯一半编程社区的风险，我还必须说这是一个庞大且复杂的非性能代码。我花了很多时间在它的肠子里四处摸索，试图调试和理解它，而我对所见所闻并没有留下深刻的印象。话虽如此，我仍然建议它作为任何寻求良好ORM的人的起点。它擅长于简单的CRUD，但我不会将其用于高效的批量查询，例如数据挖掘或数字运算。

不幸的是，我的应用程序更多地是处理数字问题（尽管也有一些CRUD），所以我决定自己编写。我从一开始就知道，与目前的其他解决方案相比，它会低于标准，但它足够好，并且可以为我提供所需的性能。现在这是真正重要的部分：它看起来非常像您的解决方案！

我认为这是您最正确的做法：您将基本信念表示为一种使命陈述，这些信念是正确的。我显然也花了很多时间思考这个问题，这是一个很难解决的问题。但是随着时间的流逝，我认为编程社区会更好地理解它，我们将创建更好的解决方案。荣誉所有以前的努力（尤其是休眠），但我认为我们可以做得更好。

您的解决方案可以更好地解决问题，但只能解决部分问题。我认为分层方法可以为我们提供我们想要的一切。/ IMO提出的是基础层。如您所建议，我认为最好是根据数据库模式自动生成此层。它应该是一个非常简单的关系对象模型，可以直接映射到数据库，并且不再需要映射。没错，数据持久性比代码持久得多，因此在此级别上，数据应该驱动代码，反之亦然。它会支持CRUD以及高性能的批量查询。我可能会在这一层实现某种L1缓存。

但是，其他ORM解决方案擅长的事情是能够以一种不太依赖基础数据库的实际结构的方式定义对象。对于此功能，我将创建另一个层。必不可少的是，该层将变得更抽象，更简单（以失去功能为代价），并建立在上一层之上。它可能利用了L2缓存。

我希望拥有更多的层，但是对我来说，关键是通过在库中提供多个入口点，您可以满足所有需求。对于那些希望将简单的CRUD解决方案直接映射到他们选择的对象的人来说，他们可以建立在顶层。对于那些寻求功能更强大，性能更高但又会增加复杂性的人，他们可以插入下层。我不会创建一种特殊的查询语言，而是为此目的公开您的查询生成器对象。而且由于代码是分层的，因此该功能自然存在而无需特殊的传递。

我认为您确实对空间有所了解，并没有重新发明轮子，而是找到了稍微不同的利基市场。坦率地说，这是一个仍然可以使用改进的轮子。您面临着与过去的强者抗衡的艰苦奋斗，但是如果您的解决方案很好，而且我认为它正在朝着这个方向发展，那么它将凭借自身的优势而受到欢迎。

“那里有很多神奇的子弹，而且不乏天真的开发者。”

没冒犯，您似乎还不完全了解在这个领域中已经完成的工作，因此正在重新发明一些轮子-经验告诉我们，您发明的轮子虽然既整洁又有趣，但几乎不会像良好或有用，因为已经可以使用精美的轮毂。

使这种API非常适合的一种情况是，当您需要数据库不可知的SQL构建器时，大多数ORM都不允许您使用它。我需要的一个大情况是生成报告。我需要以面向对象的方式构建SQL，并要在各种数据库上运行此sql进行测试。Hibernate和其他ORM非常依赖于配置，因此限制了我的sql构造，使得我无法合并xml中不存在关联的表。由于我正在开发的“报告模块”中可能存在任何关联，因此我一直在寻找不同的东西。然后我遇到了JOOQ。它只是解决了我的问题。我只需要一个只读访问权限，就不会遇到像休眠中那样痛苦的调试问题。

我实际上计划开发一种不同于普通POJO方式的数据建模方式，并使用JOOQ作为基础来构建SQL的基础之一。因此，在JOOQ之上，我计划使用HashMaps创建一种更加灵活的数据/实体建模方法。我的设计将使在一个入口点中更容易集成前端和后端设计成为可能，尽管我将使用不同的层来完成框架，就像上面的评论所说的那样。JOOQ确实会像在我自己​​的项目中一样扮演非常重要的角色，它是基础或支柱之一。

因此，请保持良好的工作习惯！

如果我正确地理解了您的工具，它将直接将对象映射到概念性的SQL框架，而不是将实现某些映射到SQL功能（ORM）的对象进行映射，几乎就像ORM一样-抽象化以实现更好的怪异控制，以便您可以使用更多的SQL功能ORM通常不会给您吗？

不知道您要解决什么问题。由于您的工具需要对SQL有深入的了解，所以人们会不会只使用SQL？您要摆脱的胶水代码吗？通过API建模而不是简单的字符串更好地验证SQL查询？

我必须承认，您的JOOQ示例看起来像SQL的LISP版本。并不是说这是一件坏事:)，而且我确实看到了一些高级的东西很有趣，但是随着您变得越来越高级（更多的配置，更少的抽象，更深入地扎入特定SQL的内部圣所），您列出的优势逐渐消失了。引擎等）

我想看到的一个建议是，在大多数ORM中我确实想念的是一个可以以非关系方式处理对象，将对象交互转换为后端（SQL，NoSQL，Topic Maps，RDF等）的框架。 。），这需要缓存所使用的模型，而不是缓存SQL交互，方言和关系思维的细节。

恕我直言，当然。:)