我们在我们的应用程序中使用 EJB3。我们的设计目标是将持久层与业务层分开。所以我们开发了用作 SLSB 的 XXXbean 类和用作持久性类的 XXXRepository 类。我们还有 POJO 实现可重用的 NON 业务逻辑（获取国家列表等），然后我们调用服务/助手类。
我们使用 EJB3 JPA（使用 Hibernate 提供程序），并且 Repository 类具有用于 CRUD 操作的所有方法和用于数据访问的 get 方法。目前 XXXRepository 类都是 POJO，我们直接从 bean XXXClasses 或从服务对象实例化这些类。
XXXRepository 类应该是 SLSB 吗？将它们转换为 SLSB 的好处和缺陷是什么？
EJB 是容器管理的 bean。这意味着，容器管理许多选项，如事务、安全、资源访问（例如数据库），并提供定时器、远程访问或拦截器等可能性。另一个优点是池和实例的重用。
我想说，如果您需要从这个容器管理的选项中获得一些东西，比如实体管理器，那么请使用 EJB，在您的情况下使用 SLSB。但是，如果您不需要任何提供的功能，那么通常的 POJO 就可以完成这项工作。
如果 XXXRepository 类没有 SLSB，它们如何访问数据库来执行 CRUD 操作？您是否直接使用休眠会话？交易如何管理？在这种情况下，在 SLSB 中转换这些类并使用注入的实体管理器可能是有意义的。
Adam Bien 写了一本名为Real World Java EE Pattern的书。在这本书中，他写了关于良好的 EJB 架构的文章，还提到了哪些类应该是 EJB（例如作为事务边界的 ServiceFacade）以及哪些类可以用作 POJO。