讨论：多层架构中是不是绝对不能把PO传递到表现层？

曾经有一个相关的问题，struts的formbean是否有用？有不少人认为formbean实在是多余的东西，因为PO可以直接代替formbean（尤其在查询时），实际我个人在设计中引入struts框架时，允许偶们的团队成员灵活“发挥”，仅仅是查询时可以不使用formbean，但总觉得不爽，不同成员写出的代码结构不同，不利于维护，尤其是交给非原作者维护时。后来利用类反射设计了一个工具类，在PO和formbean之间copy属性，虽然看起来好像“六个指头挠痒，多了一道子”，可这笨功夫是计算机做的，又不是人在做，大家心理也就平衡了:)，理论上对效率有影响，可是谁关心呢？需求维护者？用户？恐怕除了写程序的人自己，没人会关心，因为这样的差异实在是不能在感官上体现出来。:)

对于struts的form,我在这个论坛上还没有找到相关的讨论，理论上讲，form应该是作为request-driven web mvc 中的command角色而存在的，所以存在是必要的，但是它实现的就很蹩脚了，因为依赖了servlet，这点webwork就比struts有优势了，而正是由于依赖了Servlet，所以form不能充当业务级别的command或者domain model，所以你的copy动作还是千万计得要去做的,也就是说如果你不通过copy转移出form中的部分或者全部属性到"x"o,至少籍此来屏蔽掉和servlet api的依赖，那么你的bussiness layer将毫无可移植性，灵活性和美观可言，所以简单来说，这点芝麻效率还是千万别省得好啊：）

其实我想讨论的是：多层架构中是不是绝对不能把PO传递到表现层？举一个最简单的例子，一个VO可以完全和一个PO相同。这种情况下，又为什么不能把PO传递到表现层呢？所以说，批判精神要有，但是前提是你真得理解了别人在讲什么
--------------
我完全支持凤舞凰扬
任何情况下都不要做自以为聪明的事情
也不要说到底会不会移植这种话，一个系统的移植，二次开发，这种几乎是屡见不鲜了。

在开发速度优先的原则下，在你的SQL以外部分不用考虑效率问题。更何况有BeanUtil这种工具，我不认为你的得到的东西大于你付出的代价。

这段时间正在看模型层。java真是接触越多就越深奥啊。

仔细仔细的浏览了一遍贴子，感慨真的是不少。不过我是比较赞同凤舞手凰扬的：），呵呵，不管说是技术角度也好，还是个人情感角度也好，毕竟大家发贴的时候总是技术＋个人感觉，也许这句话说的厉害了，但最少我是这样子的，嗯，架构……不是一个简单的……也不是一两句话，甚至是一两天能说的清楚的……我是一只小菜鸟，继续潜水观望大仙们讨论：）

这个帖子真让我看晕头了！

　　刚看完这个帖子，收获不少。
　　我原来用 Powerbuilder + SQL Server 开发，正在学习 Java，马上就要用了，正在为架构的问题而发愁。
　　以前用 PB + MS SQL 做的超市管理系统，业务逻辑基本用存储过程实现。业务分析清楚了之后，就定义存储过程的输入输出参数，然后同时实现前端和后台代码，后台存储过程测试单独进行，这样便于协作开发、测试以及开发人员的考核。
　　但是这样做的缺点也不少，存储过程代码冗余，基本无法重用（也许可以，但我目前不知道），不好维护，客户需求变化的时候，增加字段和库表时需要改动多处存储过程代码（BTW，select 数据的时候尽量不要使用 select *，除非是判断某行是否存在）。有时候狗急跳墙干脆在 PB 中嵌入 SQL 代码，可测试性、可维护性大大的降低。
　　现在客户要求将各个门店连锁，统一采购、统一配送，总部随时可以查询各门店的销售、库存。经过一段时间的思考，准备采用 Swing  + Hessian + Tomcat + Hibernate + Postgresql（考虑到自己对 Java 不熟悉和进度，暂时不用 Spring 之类的东西），考虑到以后可能将部分功能（主要是查询）的客户端替换为 Java web start  或者 AJAX，所以在服务端建立一个 Facade，里面有许多方法供客户端调用。
　　这时候就要定义这些方法的输入输出参数，有的方法输入参数很多，使用的时候很别扭，容易出错，比如某个方法输入参数都是String，调用顺序容易弄反了，排错很麻烦。所以我想将这类的参数做成简单对象封装一下，协作开发时容易控制些。在没有看这个帖子之前，我把它叫做参数对象，放在一个叫做 com.*.*.param 的包里面，现在看来和 VO, DTO 很类似。
　　DTO is evil or not，Hibernate 团队好像也没有一致的意见。昨天看到  the groupblog of the Hibernate Team 上有一篇 Hibernate 3.2: Transformers for HQL and SQL，有兴趣的不妨看看，正好是我需要的，省去了手工将 Object[] 转换成 List 的繁琐。

又看了一下开头。

觉得分层是为了协作开发。那么减少层之间耦合性很重要。

po 不作vo用，从多人开发时维护来讲是简单一些，人少就累了。

不要在这种空洞的问题上浪费时间。架构师不是干这个的。干这个的是咨询师。

myeclipse住注册码

对应eclipse2.1版本的Myeclipse注册码：
abenmao
nAR7ZL-719-56-5467865857563467
对应eclipse3.0版本的Myeclipse注册码：
abenmao
nAR7ZL-819-56-54678656017372584

dearmite
qAR7ZL-819-56-54678656594317125