我熟悉ORM作为一个概念,几年前我甚至将nHibernate用于.NET项目; 但是,我没有跟上Java中的ORM主题,也没有机会使用这些工具.
但是,现在我可能有机会开始为我们的某个应用程序使用一些ORM工具,以试图摆脱一系列遗留Web服务.
我很难说出JPA规范之间的差异,你对Hibernate库本身的看法,以及JDO提供的内容.
所以,我知道这个问题有点开放,但我希望得到一些意见:
各自的优点和缺点是什么？
你会建议哪个新项目？
当使用一个框架与另一个框架有意义时,是否存在某些条件？
toolkit..
112
一些说明:
JDO和JPA都是规范,而不是实现.
如果您将代码限制为仅使用标准JPA,那么您的想法是可以交换JPA实现.(同上JDO.)
Hibernate可以用作JPA的一个这样的实现.
但是,Hibernate提供了一个原生API,其功能超越了JPA.
IMO,我会推荐Hibernate.
如果您需要使用特定于Hibernate的功能,那么您应该做些什么的评论/问题.有很多方法可以看看这个,但我的建议是:
如果您不担心供应商搭配的前景,那么请在Hibernate和其他JPA和JDO实现之间做出选择,包括决策中的各种供应商特定扩展.
如果您担心供应商绑定的前景,并且您不能在不诉诸供应商特定扩展的情况下使用JPA,那么请不要使用JPA.(同上JDO).
在现实中,你可能需要权衡多少你被厂商搭配担心与多少,你需要这些供应商特定的扩展.
还有其他因素,例如您/您的员工对各自技术的了解程度,产品在许可方面的成本,以及您对JDO和JPA未来将会发生什么的故事.
1> toolkit..：
一些说明:
JDO和JPA都是规范,而不是实现.
如果您将代码限制为仅使用标准JPA,那么您的想法是可以交换JPA实现.(同上JDO.)
Hibernate可以用作JPA的一个这样的实现.
但是,Hibernate提供了一个原生API,其功能超越了JPA.
IMO,我会推荐Hibernate.
如果您需要使用特定于Hibernate的功能,那么您应该做些什么的评论/问题.有很多方法可以看看这个,但我的建议是:
如果您不担心供应商搭配的前景,那么请在Hibernate和其他JPA和JDO实现之间做出选择,包括决策中的各种供应商特定扩展.
如果您担心供应商绑定的前景,并且您不能在不诉诸供应商特定扩展的情况下使用JPA,那么请不要使用JPA.(同上JDO).
在现实中,你可能需要权衡多少你被厂商搭配担心与多少,你需要这些供应商特定的扩展.
还有其他因素,例如您/您的员工对各自技术的了解程度,产品在许可方面的成本,以及您对JDO和JPA未来将会发生什么的故事.
应该补充一个重要的注意事项:虽然JPA和JDO都对RDBMS提供了很好的支持,但JDO是"数据存储"不可知的,因此不仅限于RDBMS世界.随着NoSQL的地面膨胀,一个人明智地考虑使用持久性标准,避免将他们的应用程序锁定到传统的*SQL世界.JDO应用程序可以轻松部署到非RDBMS数据存储区.支持的数据存储的完整列表可在以下网址找到:http://www.datanucleus.org/products/accessplatform/datastores.html
工具包,好又短.值得一提的另一点是,如果需要,JPA不会阻止使用特定于实现的功能.这意味着当Hibernate是一个实现时,JPA允许您使用任何Hibernate功能.
@Golfman为什么选择基于*可能*发生的事情？如果您最终需要NoSQL支持,那么没有什么可以阻止您在其他地方滚动... KISS
2> Volksman..：
确保评估JDO的DataNucleus实现.我们从Hibernate开始,因为它看起来很受欢迎,但很快就意识到它不是100%透明的持久性解决方案.有太多的警告,文档中充满了'如果你遇到这种情况,那么你必须编写这样的代码',这会带走我们想要的自由建模和编码的乐趣.JDO 从未让我调整我的代码或模型以使其"正常工作".我可以设计和编写简单的POJO,好像我只会在内存中使用它们,但我可以透明地保留它们.
JDO/DataNucleus相对于hibernate的另一个优点是它没有所有的运行时反射开销,而且内存效率更高,因为它使用构建时字节码增强(可能为大型项目的构建时间增加1秒)比hibernate的运行时反射驱动的代理模式.
你可能会发现恼人与Hibernate的另一件事是,你认为你有一个参考的对象......这是常为对象"代理".如果没有字节码增强的好处,则需要代理模式以允许按需加载(即,当您拉入顶级对象时避免拉入整个对象图).准备重写equals和hashcode,因为您认为引用的对象通常只是该对象的代理.
下面是一个你将通过Hibernate获得的令人沮丧的例子,你将无法获得JDO:
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53
如果你喜欢编码'workarounds'那么,当然,Hibernate适合你.如果您喜欢干净,纯粹,面向对象,模型驱动的开发,您可以将所有时间都花在建模,设计和编码上,而不是在丑陋的变通方法上花费几个小时来评估JDO/DataNucleus.投入的时间将被偿还一千倍.
2017年2月更新
很长一段时间以来,除了JDO持久性标准之外,DataNucleus还实现了JPA持久性标准,因此将现有的JPA项目从Hibernate移植到DataNucleus应该非常简单,只需很少的代码更改就可以获得DataNucleus的所有上述优点. ,如果有的话.所以在问题方面,选择一个特定的标准,JPA(仅限RDBMS)vs JDO(RDBMS + No SQL + ODBMSes +其他),DataNucleus同时支持,Hibernate仅限于JPA.
Hibernate DB更新的性能
选择ORM时要考虑的另一个问题是其脏检查机制的效率 - 当需要构造SQL来更新当前事务中已更改的对象时,这变得非常重要 - 尤其是当存在大量对象时.在这个SO答案中有一个详细的技术描述Hibernate的脏检查机制:
JPA与HIBERNATE插入非常慢
关于JDO,早期关键的Hibernate玩家执行的广为人知的FUD和astroturfing是不诚实和令人厌恶的,毫无疑问对JDO的采用有一些影响.现在,开发人员知道字节码增强根本不是问题,并且经常将它用于除持久性之外的许多不同目的.新的ASM字节码增强库是如此闪电般快速,你甚至没有时间在它完成之前进行呼吸.
自开始以来(http://www.javalobby.org/forums/thread.jspa?forumID=46&threadID=1326)和Hibernate之前预测JDO的失败,所以你不能责怪Hibernate.Hibernate/Toplink在Sun和JDO玩家(以及他们的OODBMS)失败时取得了成功,因为他们当时的答案更好,而不是因为营销和FUD.期.谁在乎ASM今天的速度是多么快啊**,5年多以前就不存在了,**需要的时候****JDO只是输掉了比赛.JDO在概念上是否优越？太糟糕了,它没有按时获得胜利者(并且由于JPA而不会回来).
嗯,这肯定不像过去那里至少有17个不同的专业Hibernate FUD帖子(但只来自3个不同的IP地址.数学人员=)).
众所周知,增强正是JDO如此大规模采用的原因!
为了说明我的话(另一篇文章说明了人们在开发过程中感受到的痛苦或者Hibernate为什么赢得了这场战斗):http://www.mail-archive.com/open-jpa-dev@incubator.apache.org /msg04107.html.对我来说,似乎很明显,反射/ cglib是一个解决人们问题的实际答案(人们不关心API在概念上是否优越,如果使用起来很痛苦)并且我在这里看不到任何Hibernate关键人物,只是用户.所以最后我想知道谁在传播FUD ...
"人们不关心API是否在概念上更优越,如果它使用起来很痛苦".听起来你实际上并没有通过实际使用JDO来启发自己,因为如果你有,你不会说这是一个痛苦的使用.在使用Hibernate之后,我切换到了"JDO",因为我发现API*更容易使用,并且发现JDO的透明持久性比Hibernate的反射/ cglib解决方案所提供的要少得多.以下是那些对从事实中辨别FUD感兴趣的人的一些细节:http://www.datanucleus.org/products/accessplatform_2_0/bytecode_enhancement.html
痛苦是一个非常主观的事情:虽然有些人可能会认为在编译之后等待额外的1或2秒后增强过程(这些天它比它快了一个数量级),因为痛苦的其他人可能会看到限制和限制当使用不是100%透明的持久性解决方案时,他们的设计/建模和编码是一种更为显着的痛苦,取决于其领域模型的表现力和复杂性,更多的时间致力于解决强加的约束.我个人觉得更痛苦.不同的人不同的痛苦
3> Tom..：
我最近评估并选择了一个java项目的持久性框架,我的发现如下:
我所看到的是,支持JDO的支持主要是:
你可以使用非sql数据源,db4o,hbase,ldap,bigtable,couchdb(cassandra的插件)等.
您可以轻松地从sql切换到非sql数据源,反之亦然.
没有代理对象,因此在hashcode()和equals()实现方面没那么痛苦
更多POJO,因此需要更少的解决方法
支持更多关系和字段类型
而对JPA的支持主要是:
更流行
jdo死了
不使用字节码增强
我看到很多来自JPA开发人员的亲JPA帖子,他们显然没有使用JDO/Datanucleus提供不使用JDO的弱论据.
我也看到很多来自JDO用户的帖子已经迁移到JDO并且结果更加快乐.
关于JPA更受欢迎,似乎这部分是由于RDBMS供应商的支持而不是技术上的优势.(对我来说听起来像VHS/Betamax).
JDO及其参考实现Datanucleus显然没有死,正如Google为GAE采用它并在源代码上积极开发(http://sourceforge.net/projects/datanucleus/)所示.
由于字节码增强,我看到了一些关于JDO的抱怨,但还没有解释为什么它是坏的.
事实上,在NoSQL解决方案越来越痴迷的世界中,JDO(以及数据核实现)似乎是一个更安全的选择.
我刚开始使用JDO/Datanucleus并设置它,以便我可以在使用db4o和mysql之间轻松切换.使用db4o进行快速开发很有帮助,不必过多担心数据库模式,然后一旦模式稳定部署到数据库.我也相信,以后,我可以将我的全部/部分应用程序部署到GAE,或者利用分布式存储/映射 - 减少la hbase/hadoop/cassandra而不需要太多重构.
我发现开始使用Datanucleus的最初障碍有点棘手 - 关于datanucleus网站上的文档有点难以理解 - 这些教程并不像我希望的那样容易理解.话虽如此,一旦你超越初始学习曲线,关于API和映射的更详细的文档是非常好的.
答案是,这取决于你想要什么.我宁愿拥有更清晰的代码,没有供应商锁定,更多以pojo为导向,nosql选项更受欢迎.
如果你想要温暖的挑剔感觉你和大多数其他开发者/绵羊一样,那就选择JPA/hibernate.如果你想在你的领域领先,试驾JDO/Datanucleus并自己动手.
实际上,就像我说的那样,我只是在尝试选择解决方案时给出了我所发现的印象.是的我是Java的初学者,为什么要那样相关？另一方面,你已经多次发表陈述你认为JDO已经死亡而没有提供任何事实或证据来证实它并且不承认JDO明显优越的技术领域的观点.你显然有一些个人对抗JDO/Datanucleus,并使用这些线程作为延续你的反JDO立场的手段.
这将是我的最终回复:) .. 1.如果不是为了质疑为什么提高它的相关性？我从不质疑你的诚实,我说你对其他海报并不好,而且你自相矛盾.3.没有人建议你总结8年以上 - 但用事实和例子来支持你的陈述,而不是可能冒犯的主观陈述.5.这篇文章中"hibernate/jpa/jboss是邪恶的"态度在哪里？我没看到它.我只看到你的反JDO评论.
帕斯卡尔 - 你在这里争论自己.我想你错过了FAQ的广告部分.OP询问了有关2种技术的意见.它邀请那些支持任何一方的人站出来提出他们的建设性批评/建议.对于Andy/Datanucleus和其他JDO用户来说,突出JDO的积极因素和防范批评是没有比这里推荐使用hibernate的其他人更多的广告.
你可能会参考常见问题解答中关于这个主题的帖子"Be Nice"的部分,这些部分是指责性的,对抗性的或粗鲁的.你的第一个是关于增强的讽刺评论.第二; 对早期实施的困难的咆哮并不再相关.第三是对那些可能不喜欢使用RDBMS的人进行幼稚的嘲弄和侮辱.第四是嘲笑那些对你有不同看法的人.第五是攻击; 叫我一只鹦鹉.你觉得这个'好看'吗？
如果你对JDO有过一次可怕的经历,那就解释一下可怕的东西,承认它是早期的版本,从那以后事情可能会有所改进.您还需要认识到其他人可能对您有不同的需求.仅仅因为您对JPA"满意"并且想要使用RDBMS并不意味着其他人.也许在你急于增加你的声誉时,你已经忘记了那些声誉的奖励？PS.作为开发人员,您应该真正对这些项目的健康感兴趣,因为这是推动创新和减少供应商锁定的因素.
有趣的东西 - 帕斯卡似乎不明白的一件事是,在任何事情上成为市场领导者都不会结束市场竞争.如果JPA在历史上"击败"JDO并不重要,即使由于过去的问题与JDO有关.如果现在JDO*更好*,正如比较似乎证明的那样,保持JPA流行的主要因素是流行本身(如果你同意这种推理,可能还有某些大型供应商).如果是这种情况,很少有(如果有的话)*好的理由告诉人们"JDO已经死了"或者没有使用JDO.就像苹果公司发生的事情一样 - 如果你不是最佳表现者,那么**可能会发生变化.
4> oxbow_lakes..：
你会建议哪个新项目？
我建议不要!使用Spring DAO的JdbcTemplate一起StoredProcedure,RowMapper和RowCallbackHandler来代替.
我自己在Hibernate方面的个人经验是,预先节省的时间远远超过你将花费大量时间来尝试理解和调试意外级联更新行为等问题.
如果您使用的是关系数据库,那么代码越接近它,您拥有的控制就越多.Spring的DAO层允许精确控制映射层,同时不需要样板代码.此外,它集成到Spring的事务层中,这意味着您可以非常轻松地添加(通过AOP)复杂的事务行为,而不会侵入您的代码(当然,您也可以使用Hibernate).
@grigory - 我的天浪费试图了解Hibernate的问题,如级联更新/删除,可笑的低效的查询结构等,ORM解决方案是一个"快赢"为那些与关系数据库的了解不够多的经验发言.因此,单独使用Hibernate的知识不太可能产生良好的最终产品.根据我的经验,在项目生命周期中,Hibernate(和扩展的ORM)花费的时间比节省的时间多
对不起,您对Hibernate的体验非常糟糕.我自己来自繁重的数据库/ SQL /存储过程/ JDBC学校.我不能说我是皈依者 - 上面的每一项技术仍然有一席之地.但对于通用Java 3层应用程序(无论大小),首选是ORM技术 - 最好是JPA 2.其他基于遗留代码,集成,专业知识,批量繁重的要求,实时等因素性能等可以引导(或可能不)接近不同的数据库技术堆栈.
我做了一点研究,Spring不再推荐Spring DAO(http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/orm.html):"推荐的集成方式是使用普通的Hibernate,JPA和JDO API来编写DAO代码.不再推荐使用Spring的DAO模板的旧版本;"......这是你推荐的吗？如果是这样,他们为什么不推荐它呢？
这显然是反对象关系映射(ORM)选择,由ODBC时间(90年代早期)(读取遗留)累积的大用户和代码库驱动.除非您选择继续使用ORM框架,否则没有理由不使用JDBC(有或没有Spring).想想那些有一天决定放弃FORTRAN使用C或Pascal的人.
我完全不同意上面的"快速获胜"定义 - 只需抓住Hibernate in Action(http://stackoverflow.com/questions/96729/what-are-the-best-books-for-hibernate-jpa/96865#96865) (并且它是JPA 1,JPA 2只有更好)才能完全理解这项技术所具有的功率和覆盖范围.
@oxbow_lakes:我和你在一起.我是一名开发人员DBA,正在帮助Hibernate使用Java人员对这个黑盒子进行故障排除.Hibernate当然加快了开发速度,但你只是转移了瓶颈.ORM有它们的位置(一种手段,而不是结束),但尊重RDBMS.请注意,如果民众想要使用ORM,我将永远找到工作......
不要将Hibernate用于具有许多连接和级联的非常复杂的数据结构.我已经做到了,并看到了问题.但是,对于一个简单的应用程序,JPA/Hibernate是迄今为止最快的推广方式.我从来没有喜欢花费数小时编写样板Spring RowMapper代码.这就是我们发明计算机的原因,可以自动完成这种映射.对于这样的应用程序,如果你按小时工作,RowMappers只是一个福音.
5> DataNucleus..：
JDO已经死了
JDO实际上并没有死,所以请检查你的事实.JDO 2.2于2008年10月发布JDO 2.3正在开发中.
这是在Apache下公开开发的.比JPA发布的版本更多,其ORM规范仍然在JPA2提议的功能之前
人们肯定会使用它,正如DataNucleus拥有的许多用户所证明的那样,更不用说Xcalia,Kodo.你错过了JDO和JPA没有填补同一市场的基本想法.JPA完全是RDBMS.JDO与数据存储区无关,用于RDBMS,还可用于LDAP,XML,Excel,OODBM等
我喜欢非RDBMS因素,特别是随着非RDBMS解决方案的普及,这是一个大问题.这意味着如果JPA的发展速度不够快,那么"更开放"和更灵活的替代方案(JDO)的可用性意味着JPA的受欢迎程度将趋于下降,这是必要的.不要介意JDO更完整,更优秀,更成熟或其他任何东西的技术论点 - 这不是*偏好*的问题.有意义的是,RDBMS供应商表现得很可疑--RDBMS市场主导地位的日子可能即将结束.
6> 小智..：
JDO具有比JPA更高级的功能,请参阅http://db.apache.org/jdo/jdo_v_jpa.html
7> 小智..：
我正在使用JPA(来自Apache的OpenJPA实现,它基于KODO JDO代码库,该代码库已有5年以上且极其快速/可靠).恕我直言,任何告诉你绕过规格的人都会给你不好的建议.我把时间放进去,肯定得到了回报.使用JDO或JPA,您可以通过最小的更改来更改供应商(JPA具有orm映射,因此我们谈论的可能不到一天,可能会更改供应商).如果你有像我这样的100多个表,这是巨大的.另外,你可以通过集群式缓存驱逐来构建内置缓存,这一切都很好.SQL/Jdbc适用于高性能查询,但透明持久性远优于编写算法和数据输入例程.我的整个系统中只有大约16个SQL查询(50k +代码行).
8> Volksman..：
任何说JDO已经死亡的人都是一个天体冲浪的FUD贩子,他们知道这一点.
JDO活得很好.该规范仍然比更年轻和受限制的JPA更强大,更成熟和更先进.
如果您希望仅限于JPA标准中的可用内容,您可以编写JPA并使用DataNucleus作为高性能,更透明的持久性实现,而不是JPA的其他实现.当然,如果您想要JDO带来的建模的灵活性和效率,DataNucleus也会实现JDO标准.
高尔夫球员在涉及JPA或DataNucleus的所有线程中反复粘贴相同的绝望营销材料并没有什么值得惊人的(他自1996年起使用)(http://www.theserverside.com/news/thread.tss?thread_id= 60388#337187),之前[它甚至存在](http://www.jpox.org/docs/project/history.html)!).
您的评论似乎假设我没有同时使用Hibernate和JDO.
9> tapi..：
我自己一直在研究这个问题,但两者之间并没有找到很大的区别.我认为最重要的选择是你使用哪种实现方式.对于我自己,我一直在考虑DataNucleus平台,因为它是两者的数据存储无关的实现.
为DataNucleus +1,而不是答案.
京公网安备 11010802040832号 | 京ICP备19059560号-6 