Spring + Hibernate比EJB 3更好吗？

Question

我的看法是，每当新的JEE项目启动(在这些技术适用的地方)，人们更喜欢使用Spring + Hibernate而不是EJB 3的组合。

看起来初级程序员甚至都是建议，而不是EJB。

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

Answer 1

EJB框架实际上相当不错，因为它们与JPA一起作为注释配置的持久性框架的解决方案，以及CDI，后者允许配置注释配置的依赖注入。你也可以在焊接的上面加进去。另一方面，Spring刚刚在游戏中通过注释实现了配置。

话虽如此，历史上对EJB1和2的落后不应被低估。他们不仅解决不了编写企业应用程序的问题，而且严重地失败了。设计人员完全无法了解企业和web应用程序开发人员所面临的真正问题，并提供他们实际需要的解决方案。

此外，还有一种不信任，即此时Java的当前方向存在一些严重的变化和不稳定，以及对Oracle中旧的Sun JVM的当前管理人员和所有者缺乏信心。许多人不相信Oracle会改进Java并引领这一方向，也有人担心Apache软件基金会可能会认输。越来越多的人期待着OpenJDK的未来，但它并不是企业级应用所需要的地方。

有些人认为所有这些都是死亡的味道，因为企业应用程序是Java长期以来一直是世界上第一编程语言的主要原因。这就是为什么微软一直在用.NET技术来对抗Java的原因。

非基于企业的Java应用程序开发人员正越来越多地转向OpenJDK和其他开源框架来帮助构建他们的解决方案，有些开发人员永远不会回头。可以说，让JEE重新站在合法性的前沿太少太晚了，尽管从技术上讲，JEE可以而且确实能与您的类似Spring应用程序站在一起。

Answer 2

EJB有很多包袱。这一包袱的一部分来自于这样一个事实，那就是它针对的是错误的受众。另一部分是前两个版本完全是垃圾。

如果您查看原始的EJB版本，设计就是EJB开发人员可以创建一个打包的解决方案，可以在任何符合EJB的容器中使用。对于室内商店来说，这种抽象是不必要的。这是为第三方EJB组件供应商打造繁荣市场的完美解决方案。然而，集装箱供应商过于热心于他们的市场营销，并使吨出售他们的产品作为一种可行的解决方案，为每天的发展。这相当于将所有应用程序代码构建为COM+组件。

关于原始J2EE规范的更多背景信息，大多数涉及到的供应商都拥有CORBA服务器，并希望进一步利用这些产品。EJB规范是通过IIOP协议构建的(实际上，Java是IIOP之上的一个薄薄的层)。CORBA已经因为其复杂性而被拒绝，而EJB只是伪装的CORBA，因此它带来了CORBA所带来的许多问题。实际上，与纯粹的CORBA实现相比，EJB的抽象使得使用起来更加困难。

一旦橡胶撞上了路面，人们就会意识到EJB的性能非常糟糕。由于每个调用都是远程调用，甚至在一开始就很难启动和运行应用程序，人们很快就会寻找替代方案。JSP容器中运行的Hibernate和Spring成为解决方案。

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

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