您如何看待不是真正的ORM的新Java持久性工具？[关闭]
按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 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，您认为有什么缺失？从概念上或实践上我哪里出了问题？ 批判但建设性的答案表示赞赏 我知道这场辩论是一场感性的辩论。有许多很棒的工具已经在做类似的事情。根据您自己的经验或您可能已阅读的文章，我感兴趣的是至关重要但具有建设性的反馈。