当使用外观会话 bean 时，为什么我们还应该使用业务会话 bean？
当使用外观设计模式构建应用程序的业务 EJB 层时，为什么我们仍然应该使用会话 bean 来实现实际的业务逻辑？是否有特定原因不只使用普通 Java 类（如果不需要容器管理注入）？普通 Java 类与会话 Bean 的性能如何，绕过业务会话 Bean 不会提高性能吗？
只是总结一下这两个选项：
- CLIENT ->外观 ->会话 Bean
- 客户端 ->外观 ->常规 JAVA 类
为什么使用 1 而不是 2？
When using the facade design pattern to structure an application's business EJB layer, why should we still use session beans for the actual business logic? Is there a specific reason for not just using plain Java classes (if container managed injection isn't required)? How is the performance of a plain Java class versus a session bean, wouldn't bypassing business session beans improve performance?
Just to sum up the two options:
- CLIENT -> FACADE -> SESSION BEAN
- CLIENT -> FACADE -> REGULAR JAVA CLASS
Why use 1 instead of 2?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我唯一一次认为，如果您需要与外观不同的事务性，则选项 1 是有意义的 - 例如，如果您想在外观可能属于其中的任何事务之外进行更新。
否则我的偏好永远是选项 2，它只是减少处理器时间、出错等问题。
The only time I can think that option 1 would make sense if if you need different transactionality from the facade - for example if you wanted to do an update outside of any transaction the facade might be part of.
Otherwise my preference would always be option 2, it's just less crap to eat processor time, go wrong, etc.