Session Faade核心J2EE模式的优点和缺点是什么？

它背后的假设是什么？

这些假设在特定环境中有效吗？

解决方案

Session Facade是一种奇妙的模式，它实际上是Business Facade模式的特定版本。想法是将业务功能捆绑到离散的捆绑软件中，例如TransferMoney()，Withdraw()，Deposit()...，以便UI代码根据业务操作来访问事物，而不是低级数据访问或者其他细节它不必关心。

特别是在Session Facade中，我们使用Session EJB充当业务Facade，这很不错，因为我们可以利用所有J2EE服务(身份验证/授权，事务等)...

希望对我们有帮助...

Session Facade模式的主要优点是可以按业务功能将J2EE应用程序划分为逻辑组。会话外观将由UI中的POJO调用(即业务代表)，并引用适当的数据访问对象。例如。 PersonSessionFacade将由PersonBusinessDelegate调用，然后可以调用PersonDAO。 PersonSessionFacade上的方法至少将遵循CRUD模式(创建，检索，更新和删除)。

通常，大多数会话外观都实现为无状态会话EJB。或者，如果我们在Spring地区使用AOP进行事务处理，则可以创建服务POJO，该服务可以是事务管理器的所有联接点。

SessionFacade模式的另一个优点是，任何有少量经验的J2EE开发人员都会立即了解我们。

SessionFacade模式的缺点：它假定特定的企业体系结构受到J2EE 1.4规范的限制(有关这些批评，请参阅Rod Johnson的书)。最具破坏性的缺点是它比必需的更为复杂。在大多数企业Web应用程序中，我们将需要一个servlet容器，并且Web应用程序中的大部分压力将放在处理HttpRequest或者数据库访问的层上。因此，在与EJB容器分开的进程空间中部署servlet容器似乎并不值得。 IE。对EJB的远程调用带来的痛苦大于收获。

罗德·约翰逊(Rod Johnson)声称，我们想要使用会话外观的主要原因是，如果我们正在执行容器管理的事务，而对于现代框架(例如Spring)则不需要。

他说，如果我们有业务逻辑，请将其放入POJO。 (我同意，我认为它是一种更加面向对象的方法，而不是实现会话EJB。)
http://forum.springframework.org/showthread.php?t=18155

很高兴听到相反的论点。

看来，无论何时谈论与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服务器的性能和可伸缩性且成本是一个问题的环境中，会话外观体系结构看起来吸引力较弱，因此直接与数据库进行对话可能会更简单(尽管这更多地涉及分层)。