J2EE 生了个儿子叫 TO

经典的 J2EE 设计模式
JSP-ACTION-Delegate-EJB-Service
中，业务逻辑在 Service层实现，我们经常可以看到同样签名的方法出现N次，但都是把职责一层一层向后传递，最终由Service实现。

之所以有 Delegate 是因为，EJB 的使用者不愿意面对 EJB 的复杂接口 , 而　EJB 的编写者往往更清楚应该怎样调用，所以EJB的编写者顺便编写了DELEGATE,封装了EJB的调用,并对使用着暴露了可以直接调用POJO接口.
之所以有 Service 是因为,业务逻辑代码的编写者也不愿意自己的代码从一开始就卷入 EJB 的复杂性中,他甚至还想以后可能通过 WEBSERVICE 暴露业务接口而不是 SLSB .于是,业务逻辑编写者使用 POJO 编写了业务代码,甚至还用 POJO 给复杂的业务逻辑制作了门面.

于是有了上面所列出的经典的设计模式,但是这样的设计模式 带来了很多的框架代码:

比如Delegate有这样的方法
void doMyWork(ArgType 0){ejb.doMyWork(0)};
在SLSB中必然有
void doMyWork(ArgType 0){service.doMyWork(0)};
在Service层又有
void doMyWork(ArgType 0){//real bussiness code here};

ArgType 代表某种可序列化的类型

这样必然造成一个非常大的麻烦问题，如果业务逻辑有所改变，比如需要多一个参数，那么我从Action到Service层的代码都需要修改!

于是EJB的研究者发明了TO(数据传输对象)，TO通常从ArrayList继承（以便传输分组数据，比如 网格型数据时），实现可序列化接口（一边进行远程传输）。TO的使用者通常这样做：

TO to = new TO();
Map args = new HashMap();
args.put("username",username);
args.put("password",password);
to.add(args);
ejb.doMyWork(to);

在真正需要数据的地方,再从TO里面把数据取出来进行转型。这样做的好处，当业务逻辑修改可能影响到参数的时候，需要修改的地方只有两个：Action 和 Service 。这样做也带来了缺点，所有的参数类型都是 Object 。但是，实在没有其他更好的办法来解决J2EE所带来的层间传递过多麻烦。