我是Java EE的新手，并且看到EJB在纯Java / Oracle社区中很有活力。然而，每当有人甚至说出“EJB”这个词时，每个人都会在他们的脸上表现出厌恶的表情，这让我觉得他们要么已经灭绝，要么被现代开发团队用其他一些中间件技术所取代。
就像JSP已经让位于以JSF为中心的视图技术一样，对于EJB来说也是如此吗？无论哪种方式，什么是EJB的流行替代品，它们有何不同？它们提供哪些优势或功能优于EJB？
答案 0 :(得分：14)
你的同事可能只看过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）相结合，并且回归流行的兴起很容易解释。
最近发布了一些“Spring to Java EE”迁移指南，并且在各个新闻网站上获得了非常有利的投票数，许多人表达了对EJB的支持，因为它现在是一项非常好的技术。这在五年前是不可想象的（当时EJB 3刚刚发布并且尚不为人所知）。
EJB最常见的替代方法是Spring Core（Spring Beans）。目前我认为Spring没有明显优于EJB的优势，反之亦然。这两种技术非常相似。 Spring提供了一些更方便的实用程序，而EJB在概念上更轻量级（没有XML）。这两个优点都有些主观。它们通常受到彼此功能的启发，而前者往往取决于上一次发布主要新版本的技术。
答案 1 :(得分：10)
第一版EJB在20世纪90年代末被引入。
当提到EJB时，你的同事面对的反感可能是前两个版本的EJB（例如复杂的xml部署描述符）非常复杂和麻烦的使用模式的结果。
热门替代方案是Spring framework + Hibernate / JPA
答案 2 :(得分：2)
当它们被引入时，EJB是一个解决问题的解决方案，也是一个高端解决方案。
EJB应该为程序提供一种定义工作单元的方法，使得“包含”EJB的应用程序服务器可以处理所有更困难的位，例如负载平衡，位置，故障转移，安全性，远程处理，实际上，当开发人员都被闪亮的新语言所激怒时，实现并没有真正为所有繁重的工作做好准备，他们可能已经掌握了这些功能，但配置和部署绝对是一场噩梦。 EJB规范在此期间不断变化并没有帮助，主要用例候选实体Bean的实现严重缺乏。
就我而言，我们开发了EJB来处理一直以来的批处理过程 - 每天一次获取一组事务，执行一些数据库操作，然后将输出发送给各个利益相关者并生成报告。我们不需要线程或负载平衡，更不用说大多数其他EJB功能了。最常用的是以Web为中心的应用程序方法。可以通过一些批处理作业和一些网页来完成应用程序。