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

Should I use EJB3 or Spring for my business layer?

提问by Justin Standard

My team is developing a new service oriented product with a web front-end. In discussions about what technologies we will use we have settled on running a JBoss application server, and Flex frontend (with possible desktop deployment using Adobe AIR), and web services to interface the client and server.

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

We've reached an impasse when it comes to which server technology to use for our business logic. The big argument is between EJB3 and Spring, with our biggest concerns being scalability and performance, and also maintainability of the code base.

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

Here are my questions:

以下是我的问题：

1. What are the arguments for or against EJB3 vs Spring?
   • What pitfalls can I expect with each?
   • Where can I find good benchmark information?

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

采纳答案by John Stauffer

There won't be much difference between EJB3 and Spring based on Performance. We chose Spring for the following reasons (not mentioned in the question):

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

• Spring drives the architecture in a direction that more readily supports unit testing. For example, inject a mock DAO object to unit test your business layer, or utilize Spring's MockHttpRequest object to unit test a servlet. We maintain a separate Spring config for unit tests that allows us to isolate tests to the specific layers.
• An overriding driver was compatibility. If you need to support more than one App Server (or eventually want the option to move from JBoss to Glassfish, etc.), you will essentially be carrying your container (Spring) with you, rather than relying on compatibility between different implementations of the EJB3 specification.
• Spring allows for technology choices for Persistence, object remoting, etc. For example, we are also using a Flex front end, and are using the Hessian protocol for communications between Flex and Spring.

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

回答by rustyshelf

I would definitely recommend EJB3 over spring. We find that it's more streamlined, nicer to code in, and better supported. I have in the past used Spring and found it to be very confusing, and not as well documented as EJB3 (or JPA I guess at the end of the day)

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

1. As of EJB3 you no longer have to deal with external config files, and there's only one POJO that you annotate per database table. This POJO can be passed to your web tier without any problems. IDEs like Netbeans can even auto-generate these POJOs for you. We've used EJB3 now as the back end for quite a few large scale applications, and haven't noticed any performance problems. Your Session Beans can be easily exposed as web services which you could expose to your Flex frontend. Session beans are easy to lock down at either a method or class level to assign roles and things like that if you need to.

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

I can't speak that much about spring, as I only tried it out for a few weeks. But my overall impression of it was very poor. That doesn't mean it's bad framework, but our team here has found EJB3 to be the best for the persistence/business layer.

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

回答by Brian

What are the arguments for or against EJB3 vs Spring?Spring is always innovating and recognizes real-world constraints. Spring offered simplicity and elegance for the Java 1.4 application servers and didn't require a version of the J2EE specification that no one had access to in 2004 - 2006. At this point it is almost a religious debate that you can get sucked into - Spring + abstraction + open-source versus Java Enterprise Edition (Java EE) 5.0 specifications.

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

I think Spring complements more than competeswith the Java EE specifications. As the features that were once unique to Spring continue to get rolled into the specification, many will argue that EJB 3 offers a 'good enough' feature set for most internal business applications.

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

What pitfalls can I expect with each?If your treating this as persistence issue (Spring+JPA) versus EJB3 your really not making that big of a choice.

我可以预期每个陷阱有哪些？如果您将此视为持久性问题（Spring + JPA）与 EJB3 相比，您真的不会做出那么大的选择。

Where can I find good benchmark information?I haven't followed the specj benchmark resultsfor sometime, but they were popular for a while. It seems that each vendor (IBM, JBOSS, Oracle, and Sun) get less and less interested in having a compliant server. The lists get Shorter and shorter of certified vendors as you go from 1.3, 1.4. 1.5 Java Enterprise Edition. I think the days of a giant server that is fully compliant with all the specifications are over.

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

回答by Soumitra

i have used a very similar architecture in the past. Spring + Java 1.5 + Actionscript 2/3 when combined with Flex Data Services made it all very easy (and fun!) to code. though, a Flex front end means you need adequately powerful client machines.

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

回答by James Strachan

I tend to prefer Spring over EJB3 but my recommendation would be whichever approach you take, try to stick to writing POJOs and use the standard annotations where possible, like the JSR annotations such as @PostConstruct, @PreDestroy and @Resource which work with both EJB3 or Spring so you can pick whichever framework you prefer.

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

e.g. you could decide on some project to use Guice instead for IoC.

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

If you want to use pre-request injection such as in a web application you might find Guice is quite a bit faster for dependency injection than Spring.

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

Session beans mostly boil down to dependency injection and transactions; so EJB3 and Spring are kinda similar really for that. Where Spring has the edge is on better dependency injection and nicer abstractions for things like JMS

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

回答by PEELY

The gap between EJB3 and Spring is much smaller than it was, clearly. That said, one of the downsides to EJB3 now is that you can only inject into a bean, so you can end up turning components into beans that don't need to be.

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

The argument about unit testing is fairly irrelevant now - EJB3 is clearly designed to be more easily unit testable.

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

The compatibility argument above is also kind of irrelevant: whether you use EJB3 or Spring, you're still reliant on 3rd party-provided implementations of transaction managers, JMS, etc.

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

What would swing it for me, however, is support by the community. Working on an EJB3 project last year, there just weren't a lot of people out there using it and talking about their problems. Spring, rightly or wrongly, is extremely pervasive, particularlty in the enterprise, and that makes it easier to find someone who's got the same problem you're trying to solve.

然而，对我来说，这是社区的支持。去年在一个 EJB3 项目上工作，只是没有多少人在那里使用它并谈论他们的问题。无论对还是错，Spring 都非常普遍，尤其是在企业中，这让您更容易找到遇到相同问题的人。

回答by kamal.gs

Another thing in favor of spring is that most of the other tools / frameworks out there have better support for integration with spring, most of them use spring internally as well (e.g. activemq, camel, CXF etc).

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

It is also more mature and there are a lot more resources (books, articles, best practices etc) & experienced developers available than for EJB3.

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

回答by HARIKRISHNAN RAMAKRISHNA PILLA

I think EJB is a good component technology but not a good framework.Spring is the best framework available as of today.So i should consider Spring as the best implementation of JEE in the sense of a framework and my recommendation is to use spring in every project which gives us the flexibility to integrate with any component technology easily .

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

回答by krams

Regarding your question:

关于你的问题：

What are the arguments for or against EJB3 vs Spring?

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

I suggest reading the response from the experts: A RESPONSE TO: EJB 3 AND SPRING COMPARATIVE ANALYSIS by Mark Fisher. Read the comments to find Reza Rahman's remarks (EJB 3.0).

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