使用外观设计模式构建应用程序的业务EJB层时,为什么还要将会话bean用于实际的业务逻辑?是否有一个特定的原因不仅仅使用普通的Java类(如果不需要容器管理注入)?普通Java类与会话bean的性能如何不会绕过业务会话bean提高性能?
总结两个选项:
为什么使用1而不是2?
答案 0 :(得分:2)
我唯一能认为如果您需要从外观处获得不同的事务性,那么选项1是有意义的 - 例如,如果您想在任何事务之外进行更新,那么外观可能是其中的一部分。
否则我的偏好总是选项2,吃掉处理器时间,出错等等只是少了一些。