Java框架战争：Spring和Hibernate

Question

我的开发人员正在发动内战。在一个阵营中，他们已经接受了Hibernate和Spring。在另一个阵营中，他们谴责了框架 - 他们正在考虑Hibernate。

问题是：新手Hibernate-Spring皈依者是否有可能偶然发现任何令人讨厌的惊喜，弱点或陷阱？

---

PS：我们有一个不太复杂的DAO库。我怀疑它是否具有Hibernate的丰富性，但它已达到某种程度的成熟度（即它在最后几个项目中没有被改变）。

Answer 1

他们已经谴责框架？

那太疯狂了。如果您不使用现成的框架，那么您可以创建自己的框架。它仍然是一个框架。

Answer 2

我过去曾经多次使用过Hibernate。每次我遇到边缘情况，通过文档，Google和旧版本确定语法转换为清道夫狩猎。它是一个功能强大的工具，但记录不完整（最后我看过）。

至于Spring，几乎我在过去几年中所采访或看过的每一份工作都涉及到Spring，它实际上已成为Java / Web的事实标准。使用它将有助于您的开发人员在未来更具市场价值，它将帮助您，因为您将拥有一大群能够理解您的应用程序的人。

编写自己的框架很有诱惑力，教育性和趣味性。结果不太好。

Answer 3

Hibernate有些怪癖可以肯定，但这是因为它试图解决的问题很复杂。每当有人抱怨Hibernate时，我都会提醒他们所有无聊的DAO代码，如果他们不使用它们就必须维护它们。

一些提示：

• Hibernate不能替代良好的数据库设计。 Hibernate架构没问题，但你偶尔需要调整它们
• 最终你将不得不理解Hibernate延迟加载类以及它如何影响事物。 Hibernate修改了Java字节码，如果只是为了解释对象链接为空的原因，你需要迟早深入研究深度。
• 如果可以，请使用注释。
• 花点时间学习Hibernate性能调优技术，从长远来看，它将为您节省时间。

Answer 4

如果你有一个相当复杂的数据库，Hibernate可能不适合你。在工作中，我们有一个包含大量数据的相当复杂的数据库，而Hibernate并不适用于我们。我们已经开始使用iBATIS了。但是，我知道很多开发商都成功地使用了Hibernate - 它确实为你做了很多繁重的工作 - 所以值得考虑。

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

我想说框架肯定是一件好事 - 就像其他人指出的那样，你不想重新发明轮子。 Spring包含很多模块，这意味着你不必编写这么多代码。不要屈服于“未发明在这里”的综合症！

Answer 5

这是一件事（我记得），当我在Hibernate时代时，我陷入了困境。 当您从集合中删除（多个）子对象（在父实体中），然后在一个事务中将新实体添加到同一集合中而不在中间刷新时，Hibernate将在“删除”之前执行“插入”操作。如果子表在其中一个列中有唯一约束，并且您希望不会违反它，因为您之前已经删除了一些数据（就像我一样），那么请准备好受挫。 Hibernate论坛建议：

1. 这是一个DB设计缺陷，重新设计;
2. 在删除和插入之间刷新（或提交，如果你愿意）;

我无法做到这两点，最终调整了Hibernate源代码并重新编译。它只有一行代码。但是找到一条线的努力相当于大约27杯咖啡和3个不眠之夜。

这只是您在使用Hibernate时可能最终遇到的问题和怪癖的一个例子，而您的团队中没有真正的专家（专家：对Hibernate的理念和内部工作有充分了解的人）。你的问题，解决方案，一升咖啡和不眠之夜可能会有所不同。但是你明白了。

Answer 6

延迟加载是MVC应用程序中使用Hibernate作为持久性框架的重要问题。您在控制器中加载对象并将其传递给JSP视图。由于您在控制器完成时关闭了Hibernate会话，因此该类的部分或全部成员都被代理并且一切都爆炸了。

您需要阅读Open Session in View文章以了解问题并获得解决方案。如果您正在使用Spring，那么blog article将在视图问题中描述Spring对开放会话的解决方案。

Answer 7

我没有使用过Java，但我确实在大量的Java开发人员中工作过。我得到的印象是春天还可以。但每个人都对Hibernate不满。一半的团队如果被问到“如果你能改变一件事，你会改变什么？”他们会说“摆脱Hibernate。”当我开始学习Hibernate时，它让我感到非常复杂，但是我没有学到足够的东西（谢天谢地，我已经开始）知道复杂性是否合理（可能需要解决一些复杂的问题）。 / p>

团队摆脱了Spring，转而支持Guice，但这更像是一次政治变革，至少从我的角度和我与之谈过的其他开发者的角度来看。

Answer 8

我一直认为Hibernate有点复杂且难以学习。但是，由于JPA（Java Persistence API）和EJB（Enterprise Java Beans）3.0已经存在了一段时间，所以事情变得更加容易，我更喜欢通过JavaDoc或XML来创建映射来创建映射。查看support in Hibernate。额外的好处是，如果需要，以后可以（但不是毫不费力地）更改数据库框架。我使用OpenJPA效果很好。

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

至于Spring，它有很多我喜欢的功能，但配置所需的XML量意味着我永远不会使用它。相反，我使用Guice并且非常喜欢它。

为了进行综合，我会向你怀疑开发人员如何让Hibernate更轻松地生活。至于Spring，我会认真检查Guice是否是一个可行的选择，然后尝试展示Spring / Guice如何让开发更好更容易。

Answer 9

我做了很多Spring / Hibernate开发。随着时间的推移，人们使用它们的方式已经发生了一些变化。事实证明，原始的HibernateTemplate方法难以调试，因为它吞下并包装其他有用的异常;直接与Hiberante API联系！

请继续查看生成的SQL（配置开发日志以显示SQL）。拥有数据库的抽象层并不意味着您不必再在SQL中思考;否则，你将无法获得良好的表现。

考虑一下这个项目。我曾经多次选择iBatis而不是Hibernate，因为我们有严格的性能要求，复杂的遗留模式或优秀的DBa能够编写优秀的SQL。

Answer 10

至于Hibernate：一个非常好的应用程序工具，它​​处理快速变化的数据库模式，大量表，执行大量简单的CRUD操作。涉及复杂查询的报告处理得不太好。但在这种情况下，我更喜欢混合使用JDBC或本机查询。因此，简单回答一下：我认为花在学习Hibernate上的时间是一项很好的投资（他们说它也符合EJB3.0和JPA标准，但是当我为我的个人评估它时，它并没有出现在等式中使用）。

至于春天......见The Bile Blog：）

请记住：框架不是silver bullets，但您也不应该reinvent the wheel。

Answer 11

最佳答案提到Hibernate记录不佳。我同意在线参考手册可能更完整。但是，Hibernate的作者编写的一本书“Java persistence with Hibernate”是每个Hibernate用户必读的，非常完整。

Answer 12

在我看来，Spring的最大优势在于它鼓励并支持更好的开发实践，特别是松耦合，测试和更多接口。没有Spring的Hibernate可能真的很痛苦，但两者结合起来非常有用。

将现有项目改造为任何框架都会很痛苦，但重构过程通常会对长期可维护性产生重大影响。

Answer 13

我必须同意很多这方面的帖子。我已广泛使用这两种设置。如果我可以撤消设计决策，那就是使用Hibernate。我们实际上在我们的一个产品中预算了一个版本，用于交换Hibernate for iBatis和Spring-JDBC，以实现最佳的全世界方法。我可以让一个新开发人员使用Spring-JDBC，Spring-MVC，Spring-Ioc和iBatis加快速度，而不是让我只使用Hibernate进行任务。

Hibernate对于这个KISS开发者来说太复杂了。如果您的DBA看到数据库看到的生成的SQL并通过优化版本发回给您，那么天堂会帮助您进行休眠。

Answer 14

Spring和Hibernate是很难掌握的框架。在你仍然试图弄清楚框架的时候，在紧迫的截止日期的项目中使用它们可能不是一个好主意。

框架的好处基本上是试图提供一个平台，以允许一致的代码成为产品。根据经验，建议您让开发人员熟悉框架设置最佳实践。

根据应用程序和/或数据库的设计，还有一些问题需要规避，以确保框架不会妨碍性能。

Answer 15

我发现使用众所周知的框架（例如Hibernate）确实很有帮助，因为它使您的代码适合特定的模具或思维方式。这意味着，既然您正在使用Hibernate，那么您可以通过某种方式编写代码，并且大多数（如果不是所有）了解Hibernate的开发人员都能够非常轻松地遵循您的思路。

当然，这有一个缺点。在你成为Hibernate开发人员的热门镜头之前，你会发现你正试图将一个正方形放入一个圆孔中。你知道你想做什么，以及在Hibernate进入图片之前你应该怎么做，但是找到Hibernate做这件事的方式可能需要......相当多的时间。

但是，对于那些经常聘请顾问（需要在很短的时间内了解大量源代码）或开发人员经常登录和退出的公司，或者您只是不想打赌关键开发人员将永远留下来永远不会改变工作 - 我认为Hibernate和其他标准框架是个不错的主意。

/ ACE

Answer 16

Spring和Hibernate绝对让生活更轻松。 开始使用它们可能在开始时有点耗时，但您以后肯定会从中受益。现在XML正在被注释取代，您也不需要输入数百行XML。

您可能需要考虑AppFuse来减少学习曲线：生成应用程序，研究和调整应用程序，然后离开。

Answer 17

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

这听起来像是未发明的综合症的经典案例。如果他们不热衷于春天，他们应该考虑其他选择，而不是滚动他们自己的框架（无论他们是否承认这样做）。 Guice可以想到{{3}}。还有picocontainer。根据你的需要，还有其他的。

Answer 18

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

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

如果由于数据库使用不一致，复杂的缓存机制或者无数其他原因而难以调试难以调试的代码。 Hibernate将增加很大的价值。 除了学习曲线（我花了大约1个月的实际工作时间）之外，没有任何陷阱，只要你有人为你解释基础知识。