这些对象概念的出现其实就是体现了一种层的思维,也是体现了一种框架的思维,在层与层之间我们需要什么?我们应该怎么通信,其实大家认真地用笔画上几个图就可以知道了。做web应用尤其是企业应用,切忌像楼上某些朋友说的,一个东东从头到尾,那是非常低劣和错误的设计。我们不要单纯地就为了某些对象去争论什么,它们更多的只是思维。这样的思维给我们带来了哪些好处,不言自明,当然,我们也不得不否认,我们因此失去了某些东西,比如局部的性能或者繁琐的代码和调用过程,只是自己衡量一下,它是否值得。
view的修改代表什么?是这样的,很多公司都只开发业务逻辑,也就是所谓的jar(包括EJB),而view都是由其余的厂商进行二次开发。简单举例,工作流、规则引擎、消息引擎等中间件。同一个业务逻辑组件可以有各种不同的外观表现,也许对于一个项目来说,它出现的可能性比较小,但不意味着没有,当需要把项目转换成产品的时候,不同的客户会要求不同的界面的。
为什么不把actionForm当作VO,不是说它不能做,都是java bean,有什么绝对不可能。但是作为一个架构来说,用form当VO,就意味着业务层和表示层绑定死了,界面要改,form就要改,那么业务层就一定要改,不是么?其次,用form也就将系统从架构上与某些局部框架绑定死了,也就是说,与struts绑定死了,如果出现了更强大的表示层框架,或者想移植,也基本上不存在可能了(改动太大了)。
当然,我举的这些例子,是从架构一级去考虑问题,实际中也许不会碰到,如果只是考虑普通的应用,完全是可以将form当作VO的。
view的修改代表什么?是这样的,很多公司都只开发业务逻辑,也就是所谓的jar(包括EJB),而view都是由其余的厂商进行二次开发。简单举例,工作流、规则引擎、消息引擎等中间件。同一个业务逻辑组件可以有各种不同的外观表现,也许对于一个项目来说,它出现的可能性比较小,但不意味着没有,当需要把项目转换成产品的时候,不同的客户会要求不同的界面的。
为什么不把actionForm当作VO,不是说它不能做,都是java bean,有什么绝对不可能。但是作为一个架构来说,用form当VO,就意味着业务层和表示层绑定死了,界面要改,form就要改,那么业务层就一定要改,不是么?其次,用form也就将系统从架构上与某些局部框架绑定死了,也就是说,与struts绑定死了,如果出现了更强大的表示层框架,或者想移植,也基本上不存在可能了(改动太大了)。
当然,我举的这些例子,是从架构一级去考虑问题,实际中也许不会碰到,如果只是考虑普通的应用,完全是可以将form当作VO的。