EJB和现代Java开发

Question

我是Java EE的新手,看到EJB在纯Java/Oracle社区中很活跃.然而,每当其他人甚至说出"EJB"这个词时,每个人都会在他们的脸上表现出厌恶的表情,这让我觉得他们要么已经灭绝,要么被现代开发团队用其他一些中间件技术所取代.

就像JSP已经让位于以JSF为中心的视图技术一样,EJB也是如此吗？无论哪种方式,什么是EJB的流行替代品,它们有何不同？它们提供了哪些优于EJB的优势或特性？

Answer 1

你的同事可能只看过EJB2和更早版本,它们确实是很少人喜欢使用的邪恶野兽.

在EJB2中,对于最简单的事情,必须实现非常具有侵入性的框架提供的接口,使用疯狂的生命周期方法,开发人员需要提供实现,但这与开发人员的(业务)目标无关.必须提供一些这样的工件.

此外,每个bean都必须与非常详细且难以阅读的部署描​​述符(XML文件)中的条目保持同步.好像这对开发人员来说不够侮辱,必须使用特殊工具来"增强"bean并生成代理类,骨架和存根.不支持继承等常见的OO.有一种注入,但是存在一种奇怪的注入,它将事物放在与每个bean相关联的一种地图(实际上是目录)中.

最初的EJB 1模型强制所有通信都是远程的,并且所有要分发的对象(EJB最初只被视为远程技术).因此,为了获得EJB的好处,您也被迫分配您的架构,即使这完全没必要.

也许最大的侮辱是实体Bean的概念(不要与JPA实体混淆).这类bean的缺点是如此之大,以至于即使是当时最大的EJB支持者也几乎不会向任何人推荐它.

然后作为一个非常实际的问题,EJB实现之间的兼容性至少可以说不是很好.特别是Entity Beans需要大量特定于供应商的配置.

为了最糟糕的是,需要EJB实现重量级(在安装尺寸和所需内存方面)的应用服务器,这是封闭源代码和相当昂贵(从升级或切换,从而防止企业因为投资必须是先偿还).我不记得当时很多人在博客上谈论这项技术,据我所知,这项技术大多是由销售团队向大公司的经理们提出的.

这项技术并不是普通开发人员真正喜爱的,这并不奇怪.

Sun及时意识到该技术正朝着一个完全错误的方向前进,并进行了180°转弯并开始了大规模的重新设计工作.

因此,EJB 3(2006)是一种非常理智和轻量级的方法.没有必要的框架接口来实现,没有必需的XML,只需要编写一个bean(只是简单的POJO),到处都有合理的默认值(约定优于配置),不需要特殊工具(正常的javac会do),并且在本地使用简单bean实际上是现在常见的情况.

实体豆是如此有缺陷,以至于它们完全被丢弃,取而代之的是TopLink和Hibernate提倡的更加理智的方法.

将此与广泛可用的免费,轻量级和开源实现相结合,与众多知名博客提倡技术(例如Adam Bien,Rezha Rahman,Gavin King)相结合,人们很容易解释上升到受欢迎程度.

已经有一些"春到Java EE"最近发表的迁移指南,以及那些在许多人表达自己作为一个很好的技术,现在支持EJB的各种新闻网站获得的票数非常有利的数量.这在半年前是不可想象的(当时EJB 3刚刚发布并且还不为人所知).

EJB最常见的替代方法是Spring Core(Spring Beans).目前我认为Spring没有明显优于EJB的优势,反之亦然.这两种技术非常相似.Spring提供了一些更方便的实用程序,而EJB在概念上更轻量级(没有XML).这两个优点都有些主观.它们通常受到彼此功能的启发,而前者往往取决于上一次发布主要新版本的技术.

Answer 2

EJB的第一个版本是在20世纪90年代末引入的.

当提到EJB时,您的同事面临的厌恶外观可能是前两个版本的EJB(例如复杂的xml部署描述符)的非常复杂和麻烦的使用模式的结果.

3.0和3.1是易用性的主要改进.

流行的替代方案是Spring framework + Hibernate/JPA