EJB 3.1或Spring 3..什么时候选择哪一个？
EJB在3.x版本中实现了许多改进，Spring也很常用，版本3是一个很好的替代方案。
网上有很多文章，但没有关于 ejb3x 与 spring3x 的精确比较。您对它们有什么想法吗？在现实世界的例子中，哪个在哪种条件下更好？
例如，我们想要将数据库和服务器分开，这意味着我们的应用程序将位于一台服务器上，我们的数据库将位于另一台服务器上。EJB 远程处理与 Cluster4Spring 等？
做每件事@Annotation总是好的？从来不需要配置？
EJB achieved many improvements in 3.x versions, Spring is also commonly used and version 3 is a good alternative.
There are many articles on web, but no exact comparison about ejb3x versus spring3x.. Do you have any ideas about them, in real world examples which one is better at which conditions?
For example, we want to separate db and server, which means our application will be on a server, our database will be in another server.. EJB remoting vs Cluster4Spring etc ?
Doing everyting @Annotation is always good? configuration never needed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
对于应用程序在一台服务器上运行而数据库在另一台服务器上运行的用例，EJB 和 Spring 之间的选择是无关紧要的。每个平台都支持这一点，无论是 Java SE 应用程序、简单的 Servlet 容器（如 Tomcat 或 Jetty）、PHP、Ruby on Rails 还是其他平台。
为此，您不需要任何类型的显式远程处理。您只需定义一个数据源，提供数据库服务器所在的 URL 即可。
也就是说，EJB 和 Spring Beans 确实使数据源的使用变得更加容易。它们都可以帮助您定义数据源、将其注入到 Bean 中并管理与其关联的事务。
在这两者中，EJB（以及一般的 Java EE）更加轻量级，并且更多地遵循约定优于配置的原则。 Spring 需要更多的冗长才能获得相同的东西，并且很大程度上依赖于 XML 文件，这些文件很快就会变得非常大且难以处理。硬币的另一面是 Spring 可能不那么神奇，在弄清楚你想要的所有内容后，你可能会感觉更有控制力。
另一个问题是EJB和Spring的开发方式。
EJB 是免费的（就像免费啤酒一样）、开源且非专有。非营利组织 (Apache)、开源公司 (Redhat/JBoss) 和深度商业化的闭源企业 (IBM) 都在实现 EJB。我个人会避免后者，但对每个人来说都是如此。
另一方面，Spring 是免费且开源的，但具有很强的专有性。只有一家公司在生产 Spring，那就是 Springsource。如果你不同意罗德的观点，那你就倒霉了。这不一定是坏事，但您可能需要注意其中的差异。
这确实是一场无休止的争论。一些人认为 XML 难以维护，另一些人则认为注释污染了原本纯粹的 POJO 模型。
我认为使用注释可以更干净地将 bean 注释为 EJB 无状态 bean (@Stateless) 或 JPA 实体 (@Entity)。 @EJB 或 @Inject 依赖注入也是如此。另一方面，我更喜欢将 JPQL 命名查询放在 XML 文件中而不是注释中，并且将表示纯配置数据（例如某些内容的最大值）的注入也放在 XML 中。
在 Java EE 中，每个注释也可以在 XML 中指定。如果注释和 XML 等效项同时存在，则 XML 会否决注释。这使得从默认情况下的注释开始变得非常方便，但稍后针对特定用例通过 XML 覆盖它。
Java EE 当前的偏好似乎更倾向于（简单的）注释与大量约定优于配置的结合。
For your use case where the application runs on one server and the database runs on another, the choice between EJB and Spring is irrelevant. Every platforms supports this, be it a Java SE application, a simple Servlet container like Tomcat or Jetty, PHP, Ruby on Rails, or whatever.
You don't need any kind of explicit remoting for that. You just define a datasource, provide the URL where your DB server lives and that's it.
That said, both EJB and Spring Beans do make it easier to work with datasources. They both help you defining a datasource, injecting it in beans and managing transactions associated with them.
Of the two, EJB (and Java EE in general) is more lightweight and adheres more to the convention over configuration principle. Spring requires more verbosity to get the same things and depends a lot on XML files which can quickly become very big and unwieldy. The flip side of the coin is that Spring can be less magical and you might feel more in control after having everything you want spelled out.
Another issue is the way EJB and Spring are developed.
EJB is free (as in free beer), open-source and non-proprietary. There are implementations of EJB being made by non profit organizations (Apache), open source companies (Redhat/JBoss) and deeply commercial closed source enterprises (IBM). I personally would avoid the latter, but to each his own.
Spring on the other hand is free and open-source, but strongly proprietary. There is only one company making Spring and that's Springsource. If you don't agree with Rod, then tough luck for you. This is not necessarily a bad thing, but a difference you might want to be aware of.
It's an endless debate really. Some argue that XML is hard to maintain, others argue that annotations pollute an otherwise pure POJO model.
I think that annotating a bean as being an EJB stateless bean (@Stateless) or a JPA entity (@Entity) is more cleanly done using annotations. Same goes for the @EJB or @Inject dependency injections. On the other hand, I prefer JPQL named queries to be in XML files instead of annotations, and injections that represent pure configuration data (like a max value for something) to be in XML as well.
In Java EE, every annotation can also be specified in XML. If both the annotation and the XML equivalent are present, the XML overrules the annotation. This makes it really convenient to start with an annotation for the default case, but override it later via XML for a specific use case.
The current preference in Java EE seems to be more towards (simple) annotations combined with a large amount of convention over configuration.
您应该问的真正问题是CDI/EJB 还是 Spring
The real question you should be asking is CDI/EJB or Spring
通常不是 Spring 与 EJB 之争，而是 Spring 与 Java EE 之争。 EJB 本身与 Spring Bean 相比较。它们都是一种在容器（EJB 容器或 Spring 容器）内运行的托管 bean。
总体而言，这两种技术非常相似。礼萨·拉赫曼不久前对两者进行了很好的比较。
It's often not Spring vs EJB, but Spring vs Java EE. EJB itself compares to Spring Beans. Both of them are a kind of managed beans running inside a container (the EJB container resp. Spring container).
Overall the two technologies are rather similar. Reza Rahman did a great comparison between the two a while back.
由于标准化，EJB 更具优势。如果您正在使用轻量级应用程序，我认为使用 Spring 就可以了，但如果您预计您的应用程序会很大并且需要大量内存访问和数据连接访问，您可以考虑使用 EJB 开始开发。主要原因是 EJB 框架中内置了集群和负载平衡。
在 EJB 环境中，当部署 EAR（“企业”“AR”chive）时，它可能会部署多个 EJB bean，每个 EJB bean 都有特定的用途。假设您编写了一个用于用户管理的 bean 和另一个用于产品管理的 bean。也许有一天您发现您的用户服务远远超出了您的产品访问服务，并且您希望将您的用户 bean 移动到不同机器上的不同服务器。这实际上可以在运行时完成，而无需更改代码。 Bean 可以在服务器和数据库之间移动，以适应集群和负载/数据平衡，而不会影响您的开发人员或用户，因为其中大部分可以在部署级别进行配置。
支持标准的另一个原因是知道大多数大型第三方供应商可能会支持它，从而在与新标准/服务/技术集成时减少问题 - 让我们面对现实吧，这些就像新口味的冰淇淋一样。如果它是公共规范，新的初创公司或善良的开发人员可以创建一个开源版本。
http://www.onjava.com/pub /a/onjava/2005/06/29/spring-ejb3.html
最不幸的是，即使是最聪明的设计者或程序员也无法预测他们的哪些功能可能会或可能不会被应用程序所接受。开发社区是软件变得臃肿的主要原因......Java EE 绝对是这样！
EJB's are more advantageous because of standardization. If you are working with a lightweight application I think going with Spring is fine but if you expect that your application will be big and will require lots of memory access and data connections access you may consider starting your development with EJBs. The main reason being clustering and load balancing are built into the EJB framework.
In an EJB environment, when an EAR ('E'nterprise 'AR'chive) is deployed, it may be deployed with multiple EJBs beans that each could have a specific purpose. Let say you wrote a bean for user management and another bean for product management. Maybe one day you find that your user services way exceed your products access services, and you want to move your user bean to a different server on a different machine. This can actually be done in runtime without altering your code. Beans can be moved between servers and databases, to accomodate clustering and load/data balancing without affecting your developers or your users because most of it can be configured at the deployment level.
Another reason for supporting a standard is knowing that most large third party vendors will likely support it resulting in less issues when integrating with new standard/service/technology - and let's face it, those come out like new flavours of ice-cream. And if it is in a public specification new start-up companies or kind developers can create an open-source version.
http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html
It is most unfortunate that even the most intelligent designers or programmers cannot predict which of their features may or may not be embraced by the development community which is the main reason software becomes bloated... Java EE is definitely that!
选择其中之一，但不能同时选择两者。
我个人更喜欢春天。在过去的六年里，我在一些项目上使用过，并取得了巨大的成功。它与任何软件一样可靠。
如果您选择将 EJB 添加到您的应用程序中，Spring 可以与 EJB 一起使用，但我不认为反之亦然。
如果你能负担得起的话，我会推荐单独的物理机用于 Web、应用程序和数据库服务器。
Spring 可以使用多种远程处理选项，包括 SOAP 和 REST Web 服务。 Spring bean 与 EJB 的比较超出了本问题的范围。我不明白这与你的实施有什么关系。如果您使用 Spring POJO 服务，它们位于内存中，而不需要像远程 EJB 那样的另一个网络跃点。想想福勒的分布式对象定律：“不要”。仅在有充分理由的情况下引入延迟。
Choose one or the other, but not both.
My personal preference is Spring. I've used on projects with great success for the past six years. It's as solid as any software out there.
Spring can work with EJBs if you choose to have them in your app, but I don't believe the reverse is true.
I would recommend separate physical machines for web, app, and database servers if you can afford it.
Spring can work with several remoting options, including SOAP and REST web services. A comparison of Spring beans with EJB is beyond the scope of this question. I don't see what it has to do with your implementation. If you use Spring POJO services they're in-memory rather than requiring another network hop like remote EJBs. Think of Fowler's Law of Distributed Objects: "Don't". Only introduce latency with good reason.
我想在这里提到单元测试。
在常见的Web应用程序中（控制器->服务->数据->...->视图）EJB和Spring都提供类似的结果，但Spring提供更容易的测试。
根据我的拙见，您的开发方式在几个方面有所不同：
I'd mention unit testing here.
In common web application (controller->service->data->...->view) EJB and Spring both provide similar result, but spring offers easier testing.
In my humble experience the way you develop is different in couple of aspects:
EJB 3.1 是最好的，同时也是 Java 6 EE 应用程序的标准。
Spring 仍然不支持 Java 6 CDI(weld) 也仍然很大程度上依赖于 XML 配置。 EJB 3.1 功能强大且智能。
我认为Spring 3.1不需要任何XML配置。您可以选择使用注释进行配置。
EJB 3.1 is the best while being the standard for Java 6 EE applications.
Spring still does not support Java 6 CDI(weld) also still depends a lot on XML configuration. EJB 3.1 is powerful and smart.
I think that Spring 3.1 doesn't need any XML configuration. You have the option to use annotations for configuration.