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

StackOverflow https://stackoverflow.com/questions/68527

题

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

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

这是我的问题：

  1. 支持或反对 EJB3 与 Spring 的论点是什么？
    • 每种情况下我会遇到哪些陷阱？
    • 在哪里可以找到好的基准信息？
有帮助吗？

解决方案

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

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

其他提示

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

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

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

然而，对我来说最重要的是社区的支持。去年从事 EJB3 项目时，并没有很多人使用它并谈论他们的问题。无论正确与否，Spring 都非常普遍，尤其是在企业中，这使得您可以更轻松地找到与您有相同问题并试图解决的人。

支持或反对 EJB3 与 Spring 的论点是什么？Spring 始终在创新并认识到现实世界的限制。Spring 为 Java 1.4 应用服务器提供了简单性和优雅性，并且不需要 2004 年至 2006 年无人访问的 J2EE 规范版本。在这一点上，您可能会陷入一场宗教辩论——Spring + 抽象 + 开源与 Java 企业版 (Java EE) 5.0 规范。

我认为春天 互补大于竞争 符合 Java EE 规范。随着 Spring 独有的功能不断纳入规范，许多人会认为 EJB 3 为大多数内部业务应用程序提供了“足够好”的功能集。

每种情况下我会遇到哪些陷阱？如果您将此视为持久性问题（Spring+JPA）与 EJB3 的比较，那么您真的不会做出那么大的选择。

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

我肯定会推荐 EJB3 而不是 Spring。我们发现它更加精简、更易于编码并且得到更好的支持。我过去使用过 Spring，发现它非常令人困惑，而且不像 EJB3（或者我猜最终是 JPA）那样有很好的文档记录

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

我不能过多谈论春天，因为我只尝试了几周。但我对它的总体印象很差。这并不意味着它是一个糟糕的框架，但我们的团队发现 EJB3 最适合持久层/业务层。

与 EJB3 相比，我更喜欢 Spring，但我的建议是，无论您采用哪种方法，都尝试坚持编写 POJO 并尽可能使用标准注释，例如 JSR 注释，例如 @PostConstruct、@PreDestroy 和 @Resource，它们都适用于 EJB3或 Spring，这样您就可以选择您喜欢的框架。

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

如果您想在 Web 应用程序中使用预请求注入，您可能会发现 Guice 的依赖注入比 Spring 快得多。

会话 bean 主要归结为依赖注入和事务；所以 EJB3 和 Spring 在这一点上确实有点相似。Spring 的优势在于更好的依赖注入和更好的抽象（例如 JMS）

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

关于你的问题：

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

我建议阅读专家的回复： 回应：EJB 3 和 Spring 比较分析 作者：Mark Fisher. 。阅读评论以查找 Reza Rahman 的评论 (EJB 3.0)。

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

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

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top