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

一、业务代理模式（buiness proxy）

在J2EE系统中，一般划分为表现层和业务逻辑层，为实现表现层和业务逻辑层之间的最大限度解耦，引入业务代理模式，这样，当表现层或业务逻辑层具体实现技术发生时，对彼此的影响很小，当然，如果希望实现完全解耦，我们可以使用消息系统JMS来实现，本文章只讨论同步系统范畴。

二、工厂模式

以一个Struts+Hibernate为例，以下代码是Struts的Action实现方法代码：

public ActionForward update
(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception { 
EgForm egForm = (EgForm) form;
//直接调用Hiberante实现数据持久化
getUser(request).setName
(egForm.getName()); 
return mapping.findForward(SUCCESS);
}

上述update方法代码中直接调用了后台数据库操作，带来的缺点是紧密的耦合性，当更新用户资料的需要有更多变化时，将会直接在update中加入更多业务逻辑代码，也就是说，我们的业务逻辑层代码已经完全依赖Struts这个表现层技术，万一以后我们选用其它表现层技术替代Struts后，将会触及我们业务逻辑层代码。修改后代码如下：

public ActionForward update
(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception
{ 
EgForm egForm = (EgForm)
form;
Contact contact = new Contact();
BeanUtils.copyProperties(contact, egForm); 
UserService userService = ServiceFactory.create(); 
userService.update(contact);
return mapping.findForward(SUCCESS);
}

正如图中所示，一般使用工厂模式涉及到静态类或单态模式，如上述代码中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等这样通用功能，如权限检查等是非常不方便的。

EJB直接调用实现

我们知道，EJB是业务逻辑层实现的J2EE标准技术，EJB的session bean可以作为Service实现，例如上面在update中调用EJB的代码如下：

public ActionForward update
(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception 
{ 
EgForm egForm = (EgForm)
form;
Contact contact = new Contact();
BeanUtils.copyProperties(contact, egForm); 
try{
InitialContext ic = 
new InitialContext();
UserServiceLocalHome ul =
ic.lookup("UserService"); 

UserServiceLocal userService =
ul.create();
userService.update(contact); 

}catch(){

}
 return mapping.findForward(SUCCESS);
}

在客户端表现层是直接调用EJB服务的，这种直接调用的方式类似Command模式，但是有两个缺点：

1. 客户端调用业务层实现代码较多，如上述红字行数有4行，客户端代码不简洁。

2. 无法非常自由地为所有Service动态增加新的Filter之类新功能，当然除了EJB提供的事务机制、分布集群、安全ACL等除外，如果你要增加这些新功能，可以通过ejb-jar.xml配置增加。

业务代理模式实现目标

总结上述两种实现的优缺点，衡量一个业务代理模式是否良好有下面几个指标：

1. 业务层所有服务完全展示给客户端。客户端可以完全介入调用。

2. 动态扩展性强，可为整个业务逻辑层动态扩展新的功能。　

3. 客户端调用业务层的实现代码必须简洁，至少是可配置的，最大限度降低代码的耦合性。

Ioc模式/AOP实现

目前，使用Ioc模式/AOP实现业务代理能够很好地达到上述3个目标，以JdonFramework为例：

1. 业务层所有服务完全展示给客户端。客户端可以完全介入调用。而且调用代码简洁，如下：

public ActionForward update
(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception
{ 
EgForm egForm = (EgForm) form;
Contact contact = new Contact();
BeanUtils.copyProperties(contact, egForm); 

UserService userService = 
WebAppUtil.getService("UserService", rerquest);
userService.update(contact); 

return mapping.findForward(SUCCESS);
}

上述红字两行代码不但适合调用普通POJO，而且适合调用EJB，具体是什么可以通过jdonframework.xml实现。

1. 通过加入自己的AOP拦截器可以为整个业务逻辑层动态扩展新的功能，这部分功能实现不是通过配置实现的，而是使用代码实现：

MethodInterceptor myI =
new MyInterceptor();
WebAppUtil.addInterceptor
(myI, request);

有关AOP中更复杂的pointcut实现，可以通过获得Ioc容器后自己实现：

ContainerWrapper cw =
WebAppUtil.getContainer(request);