我应该为我的业务层使用 EJB3 还是 Spring？答案

【问题标题】：Should I use EJB3 or Spring for my business layer?我应该为我的业务层使用 EJB3 还是 Spring？
【发布时间】：2010-09-09 06:31:36
【问题描述】：

我的团队正在开发一种带有 Web 前端的面向服务的新产品。在讨论我们将使用哪些技术时，我们决定运行 JBoss 应用程序服务器、Flex 前端（可能使用 Adobe AIR 进行桌面部署）以及连接客户端和服务器的 Web 服务。

在为我们的业务逻辑使用哪种服务器技术时，我们陷入了僵局。最大的争论是在 EJB3 和 Spring 之间，我们最关心的是可扩展性和性能，以及代码库的可维护性。

这是我的问题：

支持或反对 EJB3 与 Spring 的论据是什么？
- 每种方法都有哪些陷阱？
- 我在哪里可以找到好的基准信息？

【问题讨论】：

恕我直言，Spring 将很有用，并且会为您在任何环境中的开发工作做出贡献。我认为我会在每个场景中使用 Spring，并且我会考虑仅在特殊情况下使用 EJB3（例如，我有一些我需要的应用程序服务器功能（如管理选项））。

标签： java performance spring ejb-3.0 scalability

【解决方案1】：

基于性能的 EJB3 和 Spring 之间不会有太大区别。我们选择 Spring 的原因如下（问题中未提及）：

Spring 推动架构朝着更容易支持单元测试的方向发展。例如，注入一个模拟 DAO 对象对您的业务层进行单元测试，或者利用 Spring 的 MockHttpRequest 对象对一个 servlet 进行单元测试。我们为单元测试维护一个单独的 Spring 配置，允许我们将测试隔离到特定的层。
最重要的驱动程序是兼容性。如果您需要支持多个 App Server（或最终希望选择从 JBoss 迁移到 Glassfish 等），您基本上将随身携带容器（Spring），而不是依赖于不同实现之间的兼容性EJB3 规范。
Spring 允许选择持久性、对象远程处理等技术。例如，我们还使用 Flex 前端，并使用 Hessian 协议在 Flex 和 Spring 之间进行通信。

【讨论】：

我更相信依赖 Java EE 实现之间的兼容性，而不是在服务器之间携带一些专有容器。
“Java EE 实现之间的兼容性”在纸面上很好，但将 EJB 应用程序部署在不同的应用程序服务器上是另一回事，这与仅移动 Spring 容器（本身不是专有的）不同

【解决方案2】：

显然，EJB3 和 Spring 之间的差距比以前要小得多。也就是说，现在 EJB3 的一个缺点是您只能注入到 bean 中，因此您最终可以将组件变成不需要的 bean。

关于单元测试的争论现在已经无关紧要了 - EJB3 显然被设计为更容易进行单元测试。

上面的兼容性论点也有点无关紧要：无论您使用 EJB3 还是 Spring，您仍然依赖于第三方提供的事务管理器、JMS 等的实现。

然而，对我来说，社区的支持是对我的影响。去年在一个 EJB3 项目上工作，只是没有很多人在那里使用它并谈论他们的问题。无论是对是错，Spring 在企业中都非常普遍，特别是，这使得找到遇到与您要解决的相同问题的人变得更加容易。

【讨论】：

++，这样可以更轻松地找到遇到相同问题的人
这在撰写本文时可能是有效的。 2012 年，这不是真的。

【解决方案3】：

支持或反对 EJB3 与 Spring 的论据是什么？ Spring 始终在创新并认识到现实世界的限制。 Spring 为 Java 1.4 应用程序服务器提供了简单和优雅，并且不需要在 2004 - 2006 年没有人可以访问的 J2EE 规范版本。在这一点上，它几乎是一场你可以陷入的宗教辩论 - Spring + 抽象 + 开源与 Java Enterprise Edition (Java EE) 5.0 规范。

我认为 Spring 对 Java EE 规范的补充多于竞争。随着 Spring 曾经独有的特性继续被纳入规范，许多人会认为 EJB 3 为大多数内部业务应用程序提供了“足够好”的特性集。

我会遇到哪些陷阱？ 如果您将此视为持久性问题 (Spring+JPA) 与 EJB3，那么您真的不会做出那么大的选择。

我在哪里可以找到好的基准信息？ 我有一段时间没有关注specj benchmark results，但它们流行了一段时间。似乎每个供应商（IBM、JBOSS、Oracle 和 Sun）对拥有兼容的服务器越来越不感兴趣。随着您从 1.3 和 1.4 开始，列表会越来越短。 1.5 Java 企业版。我认为完全符合所有规范的巨型服务器的时代已经结束。

【讨论】：

不错。不幸的是，基准没有考虑到春天。但这总体上是很好的信息。

【解决方案4】：

我肯定会在春季推荐 EJB3。我们发现它更精简、更好地编写代码并且得到更好的支持。我过去使用过 Spring，发现它非常混乱，并且没有 EJB3（或者我猜在一天结束时的 JPA）那样有文档记录

从 EJB3 开始，您不再需要处理外部配置文件，并且每个数据库表只需注释一个 POJO。这个 POJO 可以毫无问题地传递到您的 Web 层。像 Netbeans 这样的 IDE 甚至可以为您自动生成这些 POJO。我们现在已经使用 EJB3 作为很多大型应用程序的后端，并且没有发现任何性能问题。您的会话 Bean 可以很容易地公开为您可以公开给 Flex 前端的 Web 服务。会话 bean 很容易在方法或类级别锁定，以便在需要时分配角色和类似的东西。

我不能说太多关于春天的事，因为我只试用了几个星期。但我对它的总体印象很差。这并不意味着它是一个糟糕的框架，但我们的团队发现 EJB3 是持久性/业务层的最佳选择。

【讨论】：

@rustyshelf：你能评论一下你的数据库的大小和同时登录的用户数，或者每秒的事务数吗？
我们的一个应用程序有 2500 个注册用户，其中可能最多只有 100 个用户会同时登录。其他人的同时用户较少，但自从他们上升以来一直受到打击。我们使用 Glassfish 作为我们的容器，前面有 Apache，但有时只使用 GF。
就数据库大小而言，您是指表，还是表中的行？我假设您的意思是数据，如果是这样，那么我们的表就非常“小”。我会说我们的任何表中的行数都不会超过 20,000 行。
我的意思是行，所以它很小。感谢您的观点。

【解决方案5】：

我倾向于选择 Spring 而不是 EJB3，但我的建议是无论您采用哪种方法，都尽量坚持编写 POJO 并尽可能使用标准注释，例如 JSR 注释，如 @PostConstruct、@PreDestroy 和 @Resource使用 EJB3 或 Spring，因此您可以选择您喜欢的任何框架。

例如你可以决定在某个项目上使用 Guice 来代替 IoC。

如果你想在 web 应用程序中使用请求前注入，你可能会发现 Guice 的依赖注入比 Spring 快很多。

会话 bean 主要归结为依赖注入和事务；所以 EJB3 和 Spring 确实有点相似。 Spring 的优势在于更好的依赖注入和对 JMS 之类的更好的抽象

【讨论】：

【解决方案6】：

我过去曾使用过非常相似的架构。 Spring + Java 1.5 + Actionscript 2/3 与 Flex Data Services 结合使用后，编写代码变得非常简单（而且有趣！）。不过，Flex 前端意味着您需要足够强大的客户端机器。

【讨论】：

Flex Data Services 是 BlazeDS 的专有版本吗？

【解决方案7】：

关于你的问题：

支持或反对 EJB3 与 Spring 的论据是什么？

我建议阅读专家的回复：A RESPONSE TO: EJB 3 AND SPRING COMPARATIVE ANALYSIS by Mark Fisher。阅读 cmets 以查找 Reza Rahman 的评论 (EJB 3.0)。

【讨论】：

【解决方案8】：

另一个支持 spring 的地方是大多数其他工具/框架对与 spring 的集成都有更好的支持，其中大多数也在内部使用 spring（例如 activemq、camel、CXF 等）。

与 EJB3 相比，它也更成熟，有更多资源（书籍、文章、最佳实践等）和经验丰富的开发人员。

【讨论】：

可能在撰写本文时（至少不能证明其他）。 2012 年肯定不会。

【解决方案9】：

我认为 EJB 是一个很好的组件技术，但不是一个很好的框架。Spring 是目前可用的最好的框架。所以我应该将 Spring 视为框架意义上的 JEE 的最佳实现，我的建议是使用spring 在每个项目中都使我们能够灵活地轻松与任何组件技术集成。

【讨论】：