41

EJB 在 3.x 版本中实现了很多改进，Spring 也很常用，版本 3 是一个不错的选择。

网上有很多文章，但没有关于 ejb3x 和 spring3x 的确切比较。你对它们有什么想法吗，在现实世界的例子中，哪个在哪​​个条件下更好？

例如，我们想将数据库和服务器分开，这意味着我们的应用程序将在一个服务器上，我们的数据库将在另一个服务器上.. EJB 远程处理与 Cluster4Spring 等？

做所有@Annotation 总是好的？从来不需要配置？

4

7 回答 7

56

对于应用程序在一台服务器上运行而数据库在另一台服务器上运行的用例，EJB 和 Spring 之间的选择是无关紧要的。每个平台都支持这一点，无论是 Java SE 应用程序、简单的 Servlet 容器（如 Tomcat 或 Jetty、PHP、Ruby on Rails 或其他）。

您不需要任何类型的显式远程处理。您只需定义一个数据源，提供您的数据库服务器所在的 URL，仅此而已。

也就是说，EJB 和 Spring Beans 确实使使用数据源变得更容易。它们都可以帮助您定义数据源、将其注入 bean 并管理与它们关联的事务。

在这两者中，EJB（以及一般的 Java EE）更轻量级，并且更遵循约定优于配置的原则。Spring 需要更多的冗长来获得相同的东西，并且很大程度上依赖于 XML 文件，这些文件很快就会变得非常庞大和笨拙。硬币的另一面是，春天可以不那么神奇，在把所有你想要的东西都说清楚后，你可能会感觉更有控制力。

另一个问题是 EJB 和 Spring 的开发方式。

EJB 是免费的（就像在免费啤酒中一样）、开源和非专有的。非营利组织 (Apache)、开源公司 (Redhat/JBoss) 和深度商业闭源企业 (IBM) 正在实施 EJB。我个人会避免后者，但对每个人来说都是他自己的。

另一方面，Spring 是免费和开源的，但具有很强的专有性。只有一家公司生产 Spring，那就是 Springsource。如果你不同意罗德的观点，那你就倒霉了。这不一定是一件坏事，但您可能想知道一个差异。

做所有@Annotation 总是好的？从来不需要配置？

这真是一场无休止的辩论。一些人认为 XML 难以维护，另一些人则认为注释污染了原本纯粹的 POJO 模型。

我认为将 bean 注释为 EJB 无状态 bean (@Stateless) 或 JPA 实体 (@Entity) 使用注释更干净。@EJB 或 @Inject 依赖注入也是如此。另一方面，我更喜欢将 JPQL 命名查询放在 XML 文件中而不是注释中，并且表示纯配置数据（如某物的最大值）的注入也放在 XML 中。

在 Java EE 中，每个注解也可以在 XML 中指定。如果注释和 XML 等效项都存在，则 XML 会否决注释。这使得从默认情况下的注释开始非常方便，但稍后通过 XML 覆盖它以用于特定用例。

当前 Java EE 中的偏好似乎更倾向于（简单的）注释以及大量的约定而不是配置。

于 2011-08-17T13:08:38.733 回答
14

您应该问的真正问题是CDI/EJB 或 Spring

于 2011-08-27T22:53:18.570 回答
6

通常不是 Spring 与 EJB，而是 Spring 与 Java EE。EJB 本身与 Spring Beans 相比。它们都是在容器（EJB 容器和 Spring 容器）内运行的一种托管 bean。

总体而言，这两种技术相当相似。Reza Rahman 不久前对两者进行了很好的比较。

于 2011-08-17T09:31:33.837 回答
6

由于标准化，EJB 更有优势。如果您正在使用轻量级应用程序，我认为使用 Spring 很好，但如果您希望您的应用程序很大并且需要大量内存访问和数据连接访问，您可以考虑使用 EJB 开始您的开发。集群和负载平衡的主要原因是内置在 EJB 框架中。

在 EJB 环境中，当部署 EAR（'E'enterprise 'AR'chive）时，可能会部署多个 EJB bean，每个 EJB bean 都有特定用途。假设您编写了一个用于用户管理的 bean 和另一个用于产品管理的 bean。也许有一天您发现您的用户服务方式超出了您的产品访问服务，并且您想将您的用户 bean 移动到不同机器上的不同服务器上。这实际上可以在运行时完成，而无需更改您的代码。Beans 可以在服务器和数据库之间移动，以适应集群和负载/数据平衡，而不会影响您的开发人员或您的用户，因为其中大部分都可以在部署级别进行配置。

支持标准的另一个原因是知道大多数大型第三方供应商可能会支持它，从而在与新标准/服务/技术集成时减少问题 - 让我们面对现实，这些就像新口味的冰淇淋一样出现。如果它在公共规范中，新的初创公司或开发人员可以创建一个开源版本。

http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

最不幸的是，即使是最聪明的设计师或程序员也无法预测他们的哪些特性可能会或可能不会被开发社区所接受，这是软件变得臃肿的主要原因……Java EE 绝对是这样！

于 2013-11-12T19:48:14.303 回答
3

选择其中之一，但不能同时选择两者。

我个人的偏好是春天。在过去的六年里，我在项目上取得了巨大的成功。它与那里的任何软件一样可靠。

如果您选择在您的应用程序中使用 EJB，Spring 可以与 EJB 一起使用，但我不认为反过来是正确的。

如果你能负担得起，我会推荐单独的物理机器用于 Web、应用程序和数据库服务器。

Spring 可以使用多种远程处理选项，包括 SOAP 和 REST Web 服务。Spring bean 与 EJB 的比较超出了这个问题的范围。我看不出它与您的实施有什么关系。如果您使用 Spring POJO 服务，它们是在内存中的，而不是像远程 EJB 那样需要另一个网络跃点。想想福勒的分布式对象定律：“不要”。仅在有充分理由的情况下引入延迟。

于 2011-08-16T09:34:40.390 回答
2

EJB 3.1 是最好的，同时也是 Java 6 EE 应用程序的标准。

Spring 仍然不支持 Java 6 CDI(weld) 也仍然很大程度上依赖于 XML 配置。EJB 3.1 功能强大且智能。

我认为 Spring 3.1 不需要任何 XML 配置。您可以选择使用注释进行配置。

于 2012-04-16T06:54:45.553 回答
2

我会在这里提到单元测试。在常见的 Web 应用程序（控制器->服务->数据->...->视图）中，EJB 和 Spring 都提供类似的结果，但 Spring 提供了更容易的测试。

以我的卑微经验，您的发展方式在以下几个方面有所不同：

  • 单元测试（春季获胜）。在春季，它的进展非常顺利，而在 ejb 中，您必须将 Arqullian 与 ShrinkWrap（原文如此！）一起使用，这在每次构建时运行速度都很慢。
  • 持久性（ejb 获胜）。在春天有围绕它的斗争，即谷歌“如何在实体侦听器中自动连接持久性” http://bit.ly/1P6u5WO
  • 配置（ejb 胜出）。作为从 ejb 初来乍到的新手，我对大量注释和 .xml 文件感到惊讶。
于 2015-08-05T15:21:39.163 回答