DTO模型带来的好处

    工作以来一直从事的都是Web Application 的开发，自然用的都是3层的MVC是的分层；当初刚入公司的时候2.XX的版本应用的是struts+Expresso方式，中间的事物自然都是自己进行控制，信息的传输依靠自定义的*VO 的javaBean。当然感觉这在当时也算是不错的架构了；

    大约05年初，我们进行新平台版本的开发，算是赶时髦，项目组采用了Struts + Spring + hibernate 的架构，表现层依旧采用上一版本的方式，最多就是为了解决多人开发程序是对一些配置文件更新时的冲突的问题将配置文件分解，由原来的一个分解为每个模块一个，然后再将各模块配置到根配置中。Spring是个好东西，Spring的事物管理虽然只是Spring中很小的一部分，但带来的好处却很大。大家都知道c++程序需要自己处理垃圾回收，而java利用垃圾回收器，不需要程序员自己考虑垃圾回收的事情，为我们节省了很多的时间，比如，我们的业务层需要某个服务类，根部不需要我们手动去创建对象，而是利用Spring的DI的功能，将我们需要的
对象注入近来。看到了吧，Java+Spring 多好，不用创建对象，也不用销毁对象，完全有jvm+Spring框架帮我们做，使我们完全的面向借口编程。Spring的AOP让我们从另一个角度去看问题，为我们的权限管理的实现带来很大帮助。
我们在这个版本中采用的信息传输分2种：
*VO javaBean  : 用于表现与业务层
*PO javaBean  : 用于业务层与持久层

其实我想提的问题就在这，虽然VO / PO 地划分也有它的优缺点，
1、在事物处理上分得很清
2、让系统更加松耦合
3、对于表现层不需要的信息，仅用在po，而不用在vo，对性能上有一点帮助。
4、vo / po 可以一样也可以不一样，给程序带来一定的灵活性。

但是它也有缺点，在真正的企业级开发中，数据库中对应的表一般都很多，业务比较复杂，随之而来的自然是表之间有很多1对多的关系，这种关系不仅给hibernate 带来很大的性能负载，这种情况下，vo中不能使用浅拷贝，因为对象内还有对象，这样一个javaBean如果关联的多的话，它应该是一个重量级的对象，如果页面上要实一下在处理10000甚至更多个这样的对象，你想想情况将会怎么样(带宽不够用，大量的内存被耗尽，系统运行速度急剧下降，甚至out of momery!!! )

如果，我们在做系统优化和设计的时候能使用DTO封装复杂的级联领域对象，仅仅将需要显示的数据包含进来，尽量不要再去包含其他对象，
情况是不是更好一些呢。
其实这样的问题我最初还是在Buffalo-- ajax中看到。(顺便提一下，buffalo是个好东西，以后的web程序如果没有他，会显得苍白无力)
如果你和我一样喜欢Gmail，让我们一起了解这个东西吧。(再跑题一下，buffalo封装的很好，可以用半个小时就学会怎么用它，不用去看他的源代码，她很吸引人的地方是利用javaScript实现了Burlap协议，不可思议吧)

  coolwangyu@Gmail.com