是否首选Spring + Hibernate而不是EJB 3？

我的感觉是，每当新的JEE项目开始（适用这些技术的地方）时，人们就会喜欢使用Spring + Hibernate的组合而不是EJB 3。

似乎甚至建议初级程序员而不是EJB。

这是个人喜好还是有相关原因？（例如，由早期EJB版本造成的个人伤痕导致对EJB的不信任或技术膨胀与性能原因或学习曲线有关）？

EJB 3+框架实际上非常不错，因为它们与JPA一起使用，可以回答注释配置的持久性框架，以及CDI，它允许注释配置的依赖项注入。您还可以在该焊接上方添加。另一方面，Spring现已通过注解的配置赶上了游戏。

话虽这么说，对EJB1和EJB 2的历史回退不应轻视。他们不只是不能解决与编写企业应用的问题，他们壮观失败。设计人员完全无法及时了解企业和Web应用程序开发人员面临的真正问题，从而无法提供他们实际需要的解决方案。

最重要的是，不信任的是，此时与Java的当前方向存在一些严重的变化和不稳定，并且对Oracle的当前管理员和旧Sun JVM所有者缺乏信心。许多人不相信Oracle会改进Java并引领发展方向，并且还担心Apache Software Foundation可能会失败。越来越多的人希望使用OpenJDK来实现Java的未来，但这并不是企业采用Java所必需的。

有些人将所有这些视为死亡的气味，因为企业应用程序一直是Java一直以来一直是世界上排名第一的编程语言的主要原因。这就是Microsoft通过.NET技术在Java方面获得如此多优势的原因。

基于非企业的Java应用程序开发人员正越来越多地转向OpenJDK和其他开放源代码框架来帮助构建其解决方案，有些人再也不会回头。可以说，即使从技术上讲JEE可以并且确实与可比较的Spring应用程序并驾齐驱，但要使JEE再次走在合法性的前沿，为时太晚了。

EJB有很多负担。该行李的一部分来自于针对错误的观众这一事实。另一部分是前两个版本完全废话。

如果查看原始的EJB版本，则设计是EJB开发人员可以创建可在任何EJB兼容容器中使用的打包解决方案。对于内部商店，这种抽象级别是不必要的。对于第三方EJB组件供应商来说，这是一个蓬勃发展的市场的完美解决方案。但是，容器供应商的行销热情过高，并且大量出售其产品，作为日常开发的可行解决方案。这相当于将所有应用程序代码构建为COM +组件。

对于原始J2EE规范的更多背景知识，大多数涉及的供应商都使用CORBA服务器，并希望利用这些产品向前发展。EJB规范是基于IIOP协议（实际上是Java RMI，它是IIOP上的一个薄层）构建的。CORBA已经因为其复杂性而被拒绝了，而EJB只是变相的CORBA，因此它带来了CORBA的许多问题。实际上，与纯CORBA实现相比，EJB的抽象使使用起来更加困难。

一旦遇到麻烦，人们就会意识到EJB的性能非常糟糕。由于每个呼叫都是远程呼叫，并且一开始就很难启动和正确运行应用程序，因此人们迅速寻找替代方案。在JSP容器中运行的Hibernate和Spring成为解决方案。

EJB 3“采用”了这种方法。但这仍然是一个通用的折衷方案，并没有带来太多好处。仍然没有第三方EJB组件市场，因此使用EJB容器构建您的解决方案真的没有意义。

长话短说。尽管EJB 3 在前两次迭代中是一个巨大的改进，但它仍然没有提供足够的好处来超过成本。