J2EE中几种业务代理模式的实现和比较

工厂模式优缺点
　　首先，我们总结一下上述代码使用了工厂模式所带来的好处：
　　 　
　　正如图中所示，一般使用工厂模式涉及到静态类或单态模式，如上述代码中ServiceFactory.create()可以使用静态或单态模式实现，从而形成客户端单一访问业务逻辑层入口，这样优点有两个：
　　
　　1. 由于业务逻辑入口是单一的，客户端对业务逻辑访问的可控性强，例如可动态单一入口加入权限检查或其它全局统一功能。Jive中权限正是这样实现。可控性强。
　　
　　2. 客户端代码简洁，作为客户端的表现层技术，如果我们更换了实现技术，修改的代码很少，例如上述代码中，如果不使用Struts更换了JSF等，只要拷贝上述两行红字标注的代码。
　　
　　工厂模式带来的主要缺点是：
　　
　　1. 当ServiceFactory实现子类很多时，例如除了UserService外，还有ProductService、ItemService、ImageService等等，试图使用一个总入口来涵括这些Service会造成过多代码耦合在一个类中，造成Facade模式滥用的后果。也就是说，使用工厂模式，扩展性不是很强。
　　
　　2. 由于使用静态或单态模式，在性能上，容易走入单线程、单并发用户的误区，违背了J2EE多线程并发使用的原则。
　　
　　Command模式
　　Command模式可以说解决了上面工厂模式的缺点，Command模式将所有的服务都展示给客户端，客户端可以通过特定命令形式直接指定调用后台众多Service中任何一种，Petstore中Web对EJB调用就是使用了Command模式实现。
　　
　　Command模式虽然突破了工厂模式单一入口的缺点，但是带来的缺点是易用性不够，Command模式代码实现起来不方便，这点可从Petstore绕人的WebContaoller、Event、Action等等众多类中可以看出。
　　
　　Command模式主要问题是可控性不强，如果要为所有Service动态增加类似Filter等这样通用功能，如权限检查等是非常不方便的。