73

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

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

以下是我的问题：

  1. 支持或反对 EJB3 与 Spring 的论点是什么？
    • 我可以期待每个陷阱有哪些陷阱？
    • 我在哪里可以找到好的基准信息？
4

9 回答 9

74

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

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

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

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

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

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

于 2008-12-05T13:29:19.713 回答
18

支持或反对 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 基准测试结果，但它们流行了一段时间。似乎每个供应商（IBM、JBOSS、Oracle 和 Sun）对拥有兼容的服务器越来越不感兴趣。随着您从 1.3、1.4 开始，列表会越来越短。1.5 Java 企业版。我认为完全符合所有规范的巨型服务器的时代已经结束。

于 2008-09-16T04:49:50.137 回答
9

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

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

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

于 2008-09-16T02:09:48.337 回答
7

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

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

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

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

于 2008-09-16T16:06:11.743 回答
2

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

于 2008-09-16T05:27:56.287 回答
1

关于你的问题：

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

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

于 2012-01-04T02:07:05.507 回答
0

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

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

于 2008-12-05T14:32:12.130 回答
-3

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

于 2011-02-22T02:16:39.220 回答