>的方法映射到(并且包括商业逻辑)所有的应用
中的用例。
进一步用Bank Teller例子，在bank应用中明显
有比传输存款更多的用例。使用session facade
模式，session bean将被创建来分组用例，使
相似的函数在一个bean中。因此我们可以增加其
它辅助(ancillary)银行操作到Bank Teller(如
withdrawFunds,depositFunds,getBalance())。
另外在banking应用中，为了不同目的的用例
也可以分组到一个session bean。例如，每个
银行有一个存款部门(loans department)。
需要去建模存款部门的操作的用例和Bank Teller
的用例没有关系。；所以，它们将分组成一个
LoanService session bean。相似的，一个
banking应用将也需要一个session bean来封装
和投资(investment)相关的用例。使用session
facade模式，这个baking应用的架构铺设(
architectural layout)将会如图1.4。
session facade模式工作得如此之好，以至于
常常它很容易被滥用。很通常能发现session
facade被误用的项目：
1.创建一个session bean巨类(God-class)。
常常开发者把系统中所有的用例都放在一个
session bean中。这导致臃肿的session
bean并降低开发生产力，因为所有的开发者
都需要用这一个类。session bean应该被分成
相关的用例的组群(house groupings)。
2.把领域(domain)逻辑放在session bean中。
一个设计得好的OO领域模型应该包括所有的
你的应用中的商业/用例逻辑(Fowler,2001)。
大多数session facade方法应该只是代理(
delegate)合适的entity bean,除非用例
包含需要跨不同bean而且不是直接有联系的
工作流(workflow)逻辑。
3.跨facade的商业逻辑的重复。随着项目
的增长，常常session bean方法包含重复
代码，如对checkCreditHistory的执行
逻辑，可能是任何数量的用例的工作流
的一部分。这个解决方案是增加一个服务层
(作为一个session bean或普通java类来实现)，
来封装这个可重用，用例独立(use-case-inde
pendent)的商业逻辑。这个服务层是对客户端
隐藏的。当项目的体积变大时，用常规重构
(refactoring) sessions(重复逻辑被发现
和抽出(extracted))是很有用的。
下面是session facade模式的好处：
1.低网络开销。当session bean层增加一个
层来调用，客户端现在能只在一个网络调用
中传输存款，而不是6次网络调用。在服务器
上，session bean和entity bean通过local
interface来调用，从而不导致任何网络开销。
即使entity bean只被用做remote interface,
大多数应用服务器将优化共存(collocated)的
EJB之间的通信。
2.干净和严格的商业逻辑和表示层之间的分离。
通过使用session facade,需要去执行商业逻辑
的逻辑完全被封装在session bean的方法之后。
EJB客户端无需关心表示层的事情，并且为了
一个单位的工作完成无需执行多于一个方法。
这严格的将商业逻辑从表示逻辑分离。
3.事务集成。我们的session bean封装了所有的
逻辑来完成银行传输在一个事务中。session
bean因此作为一个事物facade,对服务器端
定位事务，并且保持它们短小。事务也在
session bean方法层次被改进(demarcated)了，
通过deployment descriptor可配置。
4.低耦合。客户端和entity bean之间的请求
被session bean缓冲了。如果entity bean层
需要在将来变化，我们能避免改变客户端，
因为有session bean的间隔(indirection)。
5.好的可重用性。我们的bank teller逻辑
是被封装到一个模块化的session bean中，
能被任何类型的客户端(JSP,servlet,
application,或applet)存取。封装到session
bean的应用逻辑意味着我们的entity bean
能只包含数据和数据存取逻辑，让它们可
以跨session bean在同一个或者甚至不同应用
中可复用。
6.好的可维护性。一个人应该宣称性(declara
tively)的在Bank Teller session bean的
Depolyment Discriptor中定义事务，而不是
通过JTA编程式(programmatically)的方法。
这让我们有一个干净的对中间件和应用逻辑
的分离，增加可维护性并且减少出错的可能性。
7.一个干净的动词-名词分离。session bean
层建模了特定应用用例，我们应用中的动词，
而entity bean建模了商业对象，或“名词”，
在我们的应用中。这个架构让我们很容易
从我们的需求文档映射到一个真实的EJB架构。
session facade模式是EJB开发中的订书钉(staple)。
它加强了高效率和可重用性的设计，和清楚的分离了
表示逻辑(客户端)，商业逻辑(session facade)和
数据逻辑(entity bean,等等)。session facade描述了
一个有用的实现任何类型用例的架构；然而，如果
在自然中用例是异步的，Message facade模式提供了
一个更有伸缩性的方法。
相关模式:
Message Facade
Data Transfer Object
session facade(Alur,et al.,2001)
session facade(MartinFowler.com)
上一页 [1] [2]