何时使用 POJO 何时使用 SLSB
我们在我们的应用程序中使用 EJB3。 我们的设计目标是将持久层与业务层分离。 因此我们开发了 XXXbean 类用作 SLSB 和 XXXRepository 类用作持久化类。 我们还有 POJO 实现可重用的非业务逻辑（获取国家/地区列表等），然后我们调用服务/帮助程序类。
我们使用 EJB3 JPA（使用 Hibernate 提供程序），并且 Repository 类具有用于 CRUD 操作的所有方法和用于数据访问的 get 方法。 当前 XXXRepository 类都是 POJO，我们直接从 bean XXXClasses 或服务对象实例化这些类。
XXXRepository 类应该是 SLSB 吗？ 将它们转换为 SLSB 有何好处和缺点？
we are using EJB3 in our application. Our design aim is to separate persistence layer from Business Layer. So we have developed XXXbean classes to be used as SLSB and XXXRepository classes to be used as persistence classes. We also have POJO that implement reusable NON business logic(get list of countries etc) and we call then service/helper Classes.
We use EJB3 JPA (using Hibernate provider) and Repository classes has all the methods for CRUD operation and the get methods for data access. Currently XXXRepository classes are all POJO and we instantiate these classes directly from the bean XXXClasses or from the service Objects.
Should the XXXRepository classes be SLSB ? what would be the benefits and pitfalls of converting them to SLSB?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
EJB 是容器管理的 bean。 这意味着，容器管理许多选项，如事务、安全性、资源访问（例如数据库），并提供计时器、远程访问或拦截器等可能性。 另一个优点是实例池和实例的重用。
我想说，如果您需要此容器管理选项中的某些内容（例如实体管理器），那么请使用 EJB，在您的情况下使用 SLSB。 但如果您不需要任何提供的功能，那么通常的 POJO 就可以完成这项工作。
如果XXXRepository类不是SLSB，它们如何访问数据库来执行CRUD操作？ 你直接使用Hibernate Session吗？ 交易如何管理？ 对于这种情况，在 SLSB 中转换这些类并使用注入的实体管理器可能是有意义的。
Adam Bien 写了一本名为 真实世界 Java EE 模式 的书。 在本书中，他介绍了良好的 EJB 架构，并提到哪些类应该是 EJB（例如 ServiceFacade 作为事务边界）以及哪些类可以用作 POJO。
An EJB is a container managed bean. This means, that the container manages a lot of options like the transaction, security, resource access (e.g. database) and offers possibilities like timers, remote access or interceptors. Another advantage is the pool and the reuse of instances.
I would say, that if you need something from this container managed options like an entity manager, then use an EJB, in your case an SLSB. But if you don't need any of the provided features, then a usual POJO will do that job.
If the XXXRepository classes are no SLSB, how do they access to the database to perform the CRUD operations? Are you using the Hibernate Session directly? How are the transactions managed? It may make sense to transform thes classes in SLSB and use the injected entity manager for this case.
Adam Bien has written a book called Real World Java EE Pattern. In this book he writes about good EJB architectures and also mentions, which classes should be an EJB (for example a ServiceFacade as a transaction boundary) and which classes can be used as POJOs.