EJB 在 3.x 版本中实现了很多改进，Spring 也很常用，版本 3 是一个不错的替代方案。
网上有很多文章，但没有关于 ejb3x 和 spring3x 的确切比较。你对它们有什么想法吗，在现实世界的例子中，哪个在哪些条件下更好？
例如，我们想将 db 和 server 分开，这意味着我们的应用程序将在一个服务器上，我们的数据库将在另一个服务器上.. EJB remoting vs Cluster4Spring 等？
做每一个@Annotation 总是好的？不需要配置？
【问题讨论】：
标签： comparison ejb-3.0 ejb-3.1 spring-3
对于应用程序在一台服务器上运行而数据库在另一台服务器上运行的用例，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 中的偏好似乎更倾向于（简单的）注解以及大量的约定而不是配置。
【讨论】：
您应该问的真正问题是 CDI/EJB 还是 Spring
【讨论】：
通常不是 Spring 与 EJB，而是 Spring 与 Java EE。 EJB 本身与 Spring Beans 相比。它们都是一种在容器（EJB 容器和 Spring 容器）内运行的托管 bean。
总体而言，这两种技术非常相似。 Reza Rahman 不久前对两者进行了很好的比较。
【讨论】：
由于标准化，EJB 更有优势。如果您正在使用轻量级应用程序，我认为使用 Spring 很好，但如果您希望您的应用程序很大并且需要大量内存访问和数据连接访问，您可以考虑使用 EJB 开始您的开发。集群和负载平衡的主要原因是内置在 EJB 框架中。
在 EJB 环境中，当部署 EAR（'E'enterprise '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，Spring 可以与 EJB 一起使用，但我不认为反过来是正确的。
如果你能负担得起，我会推荐单独的物理机用于 Web、应用程序和数据库服务器。
Spring 可以使用多种远程处理选项，包括 SOAP 和 REST Web 服务。 Spring bean 与 EJB 的比较超出了这个问题的范围。我看不出它与您的实施有什么关系。如果您使用 Spring POJO 服务，它们是在内存中的，而不是像远程 EJB 那样需要另一个网络跃点。想想福勒的分布式对象定律：“不要”。仅在有充分理由的情况下引入延迟。
【讨论】：
EJB 3.1 是最好的，同时是 Java 6 EE 应用程序的标准。
Spring 仍然不支持 Java 6 CDI(weld) 也仍然很大程度上依赖于 XML 配置。 EJB 3.1 强大而智能。
我认为 Spring 3.1 不需要任何 XML 配置。您可以选择使用注解进行配置。
【讨论】：
我会在这里提到单元测试。 在常见的 Web 应用程序（控制器->服务->数据->...->视图）中，EJB 和 Spring 都提供相似的结果，但 Spring 提供了更容易的测试。
根据我的拙见，您的开发方式在以下几个方面有所不同：
【讨论】：