SessionFaçade核心J2EE模式的优点和缺点是什么？
背后的假设是什么？
这些假设在特定环境中是否有效？
答案 0 :(得分：6)
Session Facade是一个很棒的模式 - 它实际上是Business Facade模式的特定版本。我们的想法是将业务功能捆绑到离散的捆绑包中 - 例如TransferMoney（），Withdraw（），Deposit（）......这样您的UI代码就可以访问业务操作而不是低级数据访问或其他细节它不应该被关注。
特别是使用Session Facade - 您使用会话EJB充当业务外观 - 这很好，因此您可以利用所有J2EE服务（身份验证/授权，事务等）......
希望有帮助...
答案 1 :(得分：0)
Session Facade模式的主要优点是您可以通过业务功能将J2EE应用程序划分为逻辑组。 POJO将从UI（即业务代表）调用会话Facade，并引用适当的数据访问对象。例如。 PersonBusinessDelegate将调用PersonSessionFacade，然后它可以调用PersonDAO。 PersonSessionFacade上的方法至少会遵循CRUD模式（创建，检索，更新和删除）。
通常，大多数会话外观都是作为无状态会话EJB实现的。或者，如果您在Spring使用AOP进行交易，则可以创建一个服务POJO，它可以是您的事务管理器的所有连接点。
SessionFacade模式的另一个优点是任何具有一点经验的J2EE开发人员都会立即理解您。
SessionFacade模式的缺点：它假设一个特定的企业架构受到J2EE 1.4规范限制的约束（参见Rod Johnson关于这些批评的书籍）。最具破坏性的缺点是它比必要的更复杂。在大多数企业 web 应用程序中，您将需要一个servlet容器，Web应用程序中的大部分压力都将位于处理HttpRequests或数据库访问的层。因此，将servlet容器部署在EJB容器的单独进程空间中似乎不值得。即远程调用EJB会产生更多痛苦而不是获益。
答案 2 :(得分：0)
他说，如果你有业务逻辑 - 把它放在POJO中。 （我同意这一点 - 我认为它是一种更面向对象的方法 - 而不是实现会话EJB。） http://forum.springframework.org/showthread.php?t=18155
很高兴听到对比鲜明的论点。
答案 3 :(得分：0)
似乎每当你谈论任何与J2EE有关的事情时 - 幕后总会有一大堆假设 - 人们会采取某种方式 - 这会导致混乱。 （我可能也可以让问题更加清晰。）
假设（a）我们希望通过EJB规范严格使用容器管理事务
会话外观是一个好主意 - 因为它们抽象出低级数据库事务，以便能够提供更高级别的应用程序事务管理。
假设（b）你的意思是会议外观的一般建筑概念 - 那么
解耦服务和消费者并提供友好的界面是一个好主意。计算机科学通过“添加额外的间接层”解决了许多问题。
Rod Johnson写道“带有远程接口的SLSB为构建在RMI上的分布式应用程序提供了一个非常好的解决方案。但是，这是少数需求。经验表明，除非被强制要求，否则我们不想使用分布式架构。如果有必要，我们仍然可以通过在一个良好的共存对象模型之上实现远程外观来为远程客户端提供服务。“ （Johnson，R“没有EJB的J2EE开发”p119。）假设（c）您认为EJB规范（特别是会话外观组件）在良好设计的环境中是一个障碍，那么：
罗德约翰逊写道 “一般来说，在Spring应用程序中使用本地SLSB的原因并不多，因为Spring提供了比EJB更强大的声明式事务管理，而CMT通常是使用本地SLSB的主要动机。所以你可能不需要完全是EJB层。“http://forum.springframework.org/showthread.php?t=18155在Web服务器的性能和可伸缩性是主要问题 - 并且成本是个问题 - 的环境中，会话外观架构看起来不那么吸引人 - 直接与数据库交谈可能更简单（尽管这更多关于分层。）