我对EJB 3中Sessions Beans的功能感到好奇,以及它们是否可以在Spring的典型中型企业应用程序中被替换。
我找到了这篇文章: http://drag0sd0g.blogspot.com/2010/01/session-bean-alternative-spring.html 声明如下:“由于大量使用注释, 你几乎可以避免使用EJB 3的“XML Hell”;春天一样不能说。 而且,因为它是Java EE标准(EJB容器)的组成部分 与JSF,JSP,servlet,JTA事务等组件本地集成 管理器,JMS提供程序和应用程序服务器的JAAS安全提供程序。 使用Spring,您必须担心您的应用程序服务器是否完全支持具有这些本机组件的框架以及其他高性能功能,如群集,负载平衡和故障转移。如果你不担心这些事情,那么Spring根本不是一个糟糕的选择“
你同意这个说法吗?由于集合和管理功能,无状态会话Bean过去被认为是一种非常强大的企业技术。我的问题是:什么时候真的有必要使用EJB 3代替Spring或者除了Spring之外(假设在一家大公司中使用关键任务企业应用程序)?
答案 0 :(得分:7)
看起来又是另一个Java EE vs. Spring帖子......
EJB / Java EE和Spring现在是两个成熟,有竞争力的基于Java的技术堆栈。通常没有理由让事情复杂化并混淆起来。 EJB实际上学习并使用了Spring等人的许多想法。
它们都没有让你进入XML /配置地狱。两者都很容易上手,至少在基本的东西上都是如此。
Spring不仅仅是IoC / SOA /事务。它更像是一个工具箱 - 它可以与ORM和事务,Web / MVC,安全性,定时器/调度等框架集成或直接提供。您可以精确选择所需的部分。您不必被迫使用容器(您可以在独立的“桌面”应用程序中使用它。)
EJB是Java EE堆栈的一部分。它是 标准。它不像Spring那样灵活,灵活,但它的定义是所有Java EE容器都支持的。
我更喜欢Spring的自由并领先一步。
答案 1 :(得分:3)
我认为在使用EJB 3而不是Spring是绝对必要的情况下有很多情况,但有时使用EJB 3会相当容易。正如文章所述,EJB的主要优点是与各种其他JEE技术的集成,并且从EJB 3开始,Enterprise Beans的编写要比之前版本的规范简单得多。
在POJO或其他中间件技术上使用EJB的经典原因是事务。如果您的业务逻辑需要是事务性的,那么EJB提供简单的,声明性的跨国划分以及通过容器与JTA的无缝集成。虽然本文建议支持群集,负载平衡和性能管理是一个优势,但这在很大程度上取决于您选择的JEE应用服务器。
我认为决定是否使用Spring或EJB 3的关键因素是你的容器。如果您的目标容器是完全符合JEE 5+的应用程序服务器,并且您需要支持事务或消息传递等服务,那么EJB 3是显而易见的选择。但是,如果您不需要与其他JEE技术集成或部署到轻量级应用服务器,那么使用EJB只会增加不必要的开销。
答案 2 :(得分:0)
有人认为EJB3使用一系列分散在几个类上的java注释来定义数据模型优于Hibernates简单模型定义语法超出我的范围。
它是一个可维护性的噩梦。为什么你有一个交叉表?它几乎可以在代码库中的任何位置定义。一些初级程序员使用注释,现在你的java类与实际的数据库不同步。
遇到了性能问题(你会)。你不仅拥有经典的Hibernate“我不知道它正在使用什么SQL”你还有“我不知道为什么桌子就像这样构建”的问题。