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

isolation level下运行的方法，而你用session bean方法可以。
Command只能在执行它们的Command server的事务设置下运行。
这个的结果是用不同的jndi名字和事务设置(在deployment
descriptor中配置)来分发多个command server session bean。
路由逻辑组件需要被配置成发送特定的命令(command)到command
server。就是说，一种方法想发送只读command到没有事务的
session bean,然而更新命令能在command server下用tx_required
和可序列化的isolation level运行。

2.command是无状态的。command对象不能存储任何状态到执行它的
session bean中。用command模式在ejb层存储状态是不可能的。

3.笨拙的错误处理。因为command框架是通用的(generic),从
command只有CommandException能被抛出。这意味着，应用程序
异常，如NoMoneyAccountException,需要被捕获并用CommandException
封装。然后客户端需要为了特定的异常透视到command对象里面。因为
异常不是显式的宣称的，客户端失去了编译期检查异常处理的好处。

4.command在大型项目中会变得无法管理。用成千的command,
大型项目会爆炸的，很多command有重复的商业逻辑的部分，
特别当不同的项目小组使用同样的后端领域模型。这使得
维护商业逻辑层比起在session bean方法中实现用例的session
facade(很好的分组到数目很小的session bean中)困难得多。
这种类的激增将是大型项目的严重问题。

5.Command Server ejb-jar紧密的耦合到command bean和
其它ejb。因为command bean在command server的环境下
执行，为了使command bean反序列化和执行，command bean
类需要和command server session bean一起分发(在相同的
ejb-jar或EAR中)。这意味着只要command bean变化了，command
server session bean EAR或ejb-jar将需要重新分发(因此command
server classloader能读到所有包含的command的新版本)，为了
测试变化，或完全重起(如果你的应用服务器不支持热分发)。
还有，command bean需要看见任何在它们的商业逻辑中使用到的
home,remote,local home,或local interface。这需要或者当
ejb被任何它们的command bean存取时command server分发到
相同的EAR,或者存取ejb的interface和command server的ejb-jar
打包到一起。

command模式和session facade模式一起提供了两个重要的好处:
他们作为一个facade和它们在一个网络round trip中执行。另一个
command模式比session facade模式好的主要优点是把客户端从
ejb解耦了，用business delegate和session facade一起也可以达
到。因此，开发者怎样从中选择呢？把command看作是更便宜(cheaper)
的session bean会有所帮助。它们是轻量级的，更快的先导开发过程，
以后来的差的可维护性作为代价。

相关模式
command(四人帮(gof),1995)
Data Transfer HashMap