EJB设计模式(第二版)之EJB Command

EJB Command

一个ejb客户端为了完成一个用例需要执行商业逻辑。

怎样让一个开发者用一个轻量级的态度实现一个用例的
商业逻辑，使客户端和ejb解耦并且用一个事务和一次
网络调用执行用例？

设计ejb系统时的一个重要的架构决定是把商业逻辑
放到什么地方？一个用例的商业逻辑是代表你的领域
模型中的合适的方法或跨多个其它entity bean 和/或
session bean执行逻辑(工作流逻辑)。

把商业逻辑放到客户端(servlet,applet,等等)有严重的
负面效果，影响性能和可维护性，如session facade
模式所解释的。问题可以被使用session facade模式
纠正，需要把商业逻辑放到session bean中，session
bean的每个方法映射到一个特定的工作单元，或者
用例。这样做，客户端被从服务器端的对象模型屏蔽
起来，并且在一个事务和一次网络调用的round trip中
执行用例。

session facade模式自己是ejb开发的关键，不过也有
它自己的缺点。直接从客户端调用session facade会导
致客户端和服务器之间的依赖(在一个大型项目和复杂的
客户端代码中)，因为对EJB的紧耦合，如Business
Delegate模式所讨论的。这些问题能被用 business delegate
解决，增加一个封装所有对ejb层的存取的对象层。business
delegate能帮助让客户端代码简单，使客户端和服务器之间的
依赖最小。

然后session facade模式和business delegate模式一起提供了
使客户端从服务器端的实现细节解耦并允许在一个网络调用
和一个事务中执行用例的格式下写商业逻辑的最好的实践。
和通常一样，有trade-off:
1.更慢的开发过程。因为用例逻辑(经常会变化的)在一个
session bean中运行，任何时候一个用例需要改变(就是，
增加一个参数到一个方法或返回一个额外的属性)，实现
那个用例的session bean方法可能需要修改。改变一个
session bean的过程不是可以忽略不计的----一个改变通常
需要编辑3个不同的文件(接口，bean class,deployment
descriptor)并且对ejb server的重发布和可能的重起服务器。
附加的，封装变化的session be