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