我的开发人员正在进行内战。在一个营地中，他们拥抱了Hibernate和Spring。在另一个阵营中，他们谴责了正在考虑使用Hibernate的框架。

问题是：新手Hibernate-Spring转换可能会偶然遇到任何令人讨厌的惊喜，弱点或者陷阱吗？

PS：我们的DAO库不是很完善。我怀疑它是否具有Hibernate的丰富性，但它已经达到某种成熟度(即，它包含的最近几个项目中都没有更改它)。

解决方案

他们谴责了框架吗？

真是的如果我们不使用现成的框架，那么我们将创建自己的框架。它仍然是一个框架。

我在Java方面工作不多，但是我在大量Java开发人员中工作过。我得到的印象是春天还可以。但是每个人都对休眠感到不高兴。一半的团队被问到"如果你能改变一件事，你会改变什么？"他们会说"摆脱休眠"。当我开始学习Hibernate时，它给我带来了惊人的复杂性，但我学到的东西还不够多(令人感激的是，我一直在前进)以了解复杂性是否合理(也许需要解决一些复杂的问题)。

团队摆脱了Spring的支持，转而使用Guice，但这至少是一种政治变革，至少从我和与我交谈过的其他开发人员的角度来看。

框架不是邪恶的。甚至Java SDK都是一个框架。

他们可能要对抗的是框架扩散。我们不应该仅仅为项目带来一个框架，它应该在合理的时间内带来一致的价值。每个框架都需要学习曲线，但是以后应该为我们提供更高的生产力和功能。

如果我们由于数据库使用不一致，缓存机制复杂或者其他原因而难以调试的代码困扰。休眠将增加巨大的价值。
除了学习曲线(对我来说大约花了一个月的实践时间)之外，如果我们周围有人为我们解释基本知识，则没有任何陷阱。

Hibernate确实有一些怪异之处，但这是因为它试图解决的问题很复杂。每当有人抱怨Hibernate时，我都会使他们想起所有无聊的DAO代码，如果不使用它们，则必须维护它们。

一些提示：

• Hibernate不能替代良好的数据库设计。休眠模式还可以，但偶尔需要调整它们
• 最终，我们将必须了解Hibernate惰性加载类的方式以及对事物的影响。 Hibernate修改了Java字节码，如果只是为了解释为什么对象链接为空，则我们迟早需要深入研究。
• 如果可以，请使用注释。
• 花点时间学习Hibernate性能调优技术，从长远来看将为我们节省很多时间。

我已经做了很多Spring / Hibernate开发。随着时间的流逝，人们将两者结合使用的方式已经发生了一些变化。事实证明，原始的HibernateTemplate方法难以调试，因为它会吞并并包装其他有用的异常。直接与Hiberante API通讯！

请继续查看生成的SQL(配置开发日志以显示SQL)。在数据库中拥有抽象层并不意味着我们不必再考虑使用SQL。否则，我们将无法获得良好的性能。

考虑该项目。在我们有严格的性能要求，复杂的旧架构或者优秀的DBa能够编写出色的SQL的场合，我选择了iBatis而不是Hibernate。

@slim今天早上我又和你在一起。

这听起来像"这里没有发明综合症"的经典案例。如果他们不热衷于春季，他们应该考虑其他选择，而不是滚动自己的框架(无论他们是否承认这样做)。 Guice想到了一种可能性。也是picocontainer。根据需要，还有其他地方。

如果数据库相当复杂，则Hibernate可能不适合我们。在工作中，我们有一个相当复杂的数据库，其中包含大量数据，而Hibernate并不能真正为我们服务。我们已经开始使用iBATIS。但是，我知道许多成功使用Hibernate的开发商店，它确实为我们做了大量艰苦的工作，因此值得考虑。

如果我们知道如何正确使用Spring，Spring是一个很好的工具。

我想说框架绝对是一件好事，就像其他人指出的那样，我们不想重蹈覆辙。 Spring包含许多模块，这意味着我们不必编写太多代码。不要屈服于" Not Invented Here"综合症！

至于Hibernate：这是一个非常好的应用程序工具，可以处理快速变化的数据库模式，大量的表，执行许多简单的CRUD操作。涉及复杂查询的报告处理起来不太好。但是在这种情况下，我更喜欢混合使用JDBC或者本机查询。因此，作为一个简短的答案：我认为花时间学习Hibernate是一项不错的投资(他们说它也符合EJB3.0和JPA标准，但是当我为个人进行评估时，这并没有成为问题使用)。

至于春天...请参阅The Bile Blog :)

请记住：框架不是万灵丹，但是我们也不应该重新发明轮子。

(这是我记忆中的一件事)，那时我正处于休眠状态。
当我们从一个集合(在父实体中)删除(几个)子对象，然后在一个事务中将新实体添加到同一集合中而不在中间进行刷新时，Hibernate会在"删除"之前执行"插入"。如果子表在其列之一中具有唯一约束，并且我们希望自己不会违反它，因为我们之前已经删除了一些数据(就像我以前一样)，那么就准备沮丧。
休眠论坛建议：

• 重新设计是一个DB设计缺陷。
• 在删除和插入之间刷新(或者提交，如果愿意的话)；

我不能两者都做，最后调整了Hibernate源代码并重新编译。它只有1行代码。但是，发现一条线等于大约27杯咖啡和3个不眠之夜的努力。

这只是我们在团队中没有真正专家的情况下使用Hibernate时可能遇到的问题和怪癖的一个示例(专家：对Hibernate的理念和内部工作有充分了解的人)。问题，解决方案，咖啡量和不眠之夜的计数可能会有所不同。但是你明白了。

我发现使用众所周知的框架(例如Hibernate)确实有帮助，因为它使代码适合特定的模型或者思维方式。这意味着，由于我们使用的是Hibernate，因此我们将以某种方式编写代码，并且大多数(如果不是全部)了解Hibernate的开发人员将能够很轻松地遵循思路。

当然，这有一个缺点。在成为热门Hibernate开发人员之前，我们会发现我们正在尝试将正方形放入圆形孔中。我们知道要做什么，以及在Hibernate出现之前我们应该如何做，但是找到Hibernate的方式可能要花很多时间。

不过，对于经常雇用顾问的公司(他们需要在短时间内了解很多源代码)，开发人员经常登录并退出的公司，或者我们不想打赌关键开发人员会永远保持永不改变工作-Hibernate和其他标准框架是我认为的一个好主意。

/高手

我一直发现Hibernate有点复杂并且很难学习。但是随着JPA(Java持久性API)和EJB(Enterprise Java Beans)3.0的存在已经有一段时间了，事情变得简单得多，我更喜欢为类添加注释以通过JavaDoc或者XML创建映射。查看Hibernate中的支持。额外的好处是可以(但并非毫不费力)稍后在需要时更改数据库框架。我使用OpenJPA取得了不错的效果。

最近，我越来越多地使用JCR(Java内容存储库)。我喜欢我的模块可以共享一个数据存储并且可以让结构和属性发展的方式。我发现使用节点和属性比将对象映射到数据库要容易得多。 Hymanrabbit是一个很好的实现。

至于Spring，它具有很多我喜欢的功能，但是配置所需的XML数量意味着我将永远不会使用它。相反，我利用Guice并绝对喜欢它。

总而言之，我会让我们怀疑开发人员Hibernate如何使他们的生活更轻松。至于Spring，我会认真检查Guice是否是可行的选择，然后尝试说明Spring / Guice如何使开发变得更好和更容易。

Spring和Hibernate无疑使生活更轻松。
开始使用它们可能在一开始会花费一些时间，但是稍后我们肯定会从中受益。现在XML被注解取代了，我们也不需要键入数百行XML。

我们可能需要考虑使用AppFuse来减少学习难度：生成应用程序，对其进行研究和调整，然后再使用。

延迟加载是使用Hibernate为其持久性框架的MVC应用程序中的大难题。我们将对象加载到控制器中，并将其传递到JSP视图。类的某些或者全部成员都被代理，并且一切都变了，因为控制器完成后，Hibernate会话已关闭。

我们将需要阅读"在View中打开会话"文章以了解问题并获得解决方案。如果我们使用的是Spring，则此博客文章将介绍针对打开的会话中的Spring解决方案。

Spring和Hibernate是难以掌握的框架。在我们仍然试图弄清楚框架的同时，在期限紧迫的项目中使用它们可能不是一个好主意。

框架的好处基本上是试图提供一个平台，以使一致的代码成为产品。根据经验，最好让开发人员对框架设定的最佳实践有丰富的经验。

根据应用程序和/或者数据库的设计，还需要规避某些怪癖，以确保框架不会影响性能。

过去，我已经多次使用过Hibernate。每次遇到极端情况时，确定语法都会成为文档，Google和旧版本中的"拾荒者"。它是一个功能强大的工具，但是文档记录很差(我上次看过)。

至于Spring，在过去的几年中，我采访或者研究的几乎每项工作都涉及Spring，它实际上已成为Java / web的事实上的标准。使用它可以帮助开发人员在将来更具市场价值，并且可以帮助到我们，因为我们将拥有大量了解应用程序的人员。

编写自己的框架很诱人，很有教育意义并且很有趣。结果不太好。

我必须同意这一方面的许多帖子。我已经在各种设置中广泛使用了这两种方法。如果我可以撤销一个设计决定，那将是使用Hibernate。实际上，我们预算了其中一种产品的发行版，以将Hibernate换成iBatis和Spring-JDBC，从而获得了世界上最好的方法。我可以让一个新的开发人员更快地使用Spring-JDBC，Spring-MVC，Spring-Ioc和iBatis，这比我刚刚给它们分配Hibernate任务要快。

对于这个KISS开发人员来说，Hibernate太复杂了。如果DBA看到数据库看到的生成的SQL并以优化的版本将我们发送回去，那么Heaven可以休眠。

在我看来，Spring的最大优点是它鼓励并支持更好的开发实践，尤其是松散的耦合，测试和更多的接口。没有Spring的Hibernate确实很痛苦，但是将两者结合在一起非常有用。

将现有项目改造为任何框架将很痛苦，但是重构过程通常对于长期可维护性具有重大好处。

最重要的答案提到了Hibernate的文献资料很少。我同意在线参考手册可能会更完整。但是，由Hibernate的作者写的一本书" Java与Hibernate的持久性"是每个Hibernate用户必读的并且非常完整。