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

它只是简单的对command设置属性，直到command包含所有需要
执行用例的数据。这时客户端能调用command的execute方法，
然后简单的执行command上的get直到得到所有command和用例
的结果数据。

当客户端执行command,有趣的事情在幕后发生。不是本地执行，
command实际上传输到一个远程ejb服务器并在ejb服务器的JVM
中执行。然而，所有的在执行用例的过程中被command调用的
ejb发生在ejb服务器上，一个用例能在一个事物中执行。这个
行为的实现机制晚些时候将在这个模式的讨论中讲解。

使用transfunds例子，一个客户端将设置用来取钱,存钱，传输
量的账号的ID。调用transfunds command的execute后，客户端
将得到最后账户的平衡，如1.8图所示。

可能Command模式最完善的实现之一是IBM的Command框架，和websphere
一同出现，是IBM为电子商务的模式的一部分。有很多实现ejb command
模式的方法，不过他们都有3个要素：

1.Command bean。一个有get,set和一个包含需要执行一个用例的商业逻辑
的execute方法的简单的java bean。command bean是应用程序开发者需要
写的command模式的唯一部分，下面所解释的其他组件是可以跨工程复用的。

2.客户端路由逻辑。通常负责执行命令(command)并把它发送到远程ejb
服务器的一个类的框架。这个路由逻辑通常对客户端不可见，通过调用
command的execute方法来触发。路由逻辑/框架是一个普通的能被跨工程
复用的类的集合。

3.远程Command server。Command server是简单的接受命令(commands)
并执行它们的服务。应用到ejb,command server类是一个接受命令(command)
作为参数并本地执行之的stateless session bean。Command server也是
普通的(generic)并且完全跨项目可复用。

客户端和这3个组件之间的交互如图1.9所示。在这个例子中，客户端调用
路由逻辑组件上的executeCommand方法。在IBM command框架中，客户端
只需要调用command自己的execute，因为方法调用将实际上被command的
超类接收到，它是路由逻辑框架的一部分。

在幕后，CommandExecutor代理了对一个ejb command目标(因为它是路由
逻辑的一部分，所以没有在图1.9中表示出来)的调用,它被编码成知道ejb
并且知道怎样发送命令(command)到command server stateless session
bean。通过接受命令(command),command server简单的调用command的
execute方法，command然后继续它的商业逻辑。

Command模式的好处如下:
1.因为轻量级的开发/分发过程，方便了RAD。
把一个用例写成Command bean比写成一个session
bean方法相对更容易和快速去分发和测试。经常
的变化能在一个普通java类上做，而不是一个
完全的EJB。

2.把商业逻辑从表示逻辑分离。Command通过封装
command内的商业逻辑来作为服务器上对象模型
的一个facade，只暴露一个简单的command接口
让客户端使用。这个分离让客户端和服务器分开
的演进。

3.强制用例在一个单独的round trip中执行。
因为command实际上在EJB服务器上执行，只需要
一次网络调用(和一个事务)来完成一个复杂的
用例。

4.使客户端从ejb解耦。客户端是完全的从服务器的
实现细节解耦的--所有它们能看见的只是command bean,
command bean看上去象是本地类。

5.命令(command)可以本地执行或产生哑(dummy)数据。
空的或虚的命令(command)能在项目开始前被创建，
允许表示层开发者去对于商业逻辑和ejb小组相对独立的
写，编译，和测试他们的代码。

很多方面command模式听起来像个终极的解决方案,综合了
session facade和business delegate的好处，和一个
轻量级的基础。然而，好处和通常一样，被重要的trade-off
所平衡:
1.非常粗粒度的事务控制。因为command只是普通java bean,
没有自动的标记一个command去在一个特定的事务设置或