请问一个开发架构问题?

看了精华区的“结合struts和hibernate谈J2EE架构的数据表示”一文，po的使用范围最多到action层。
那么当用hibernate查询出一个List的时候，该怎么样显示到jsp中呢？显然将list存到request中然后在页面中获取并循环显示，就违反了这个规则，大家是怎么做的？
因为我想建个对应的vo，然后将list中的po转换为vo会增加很大的工作量啊，现在开发效率也是不得不考虑的问题。

po转化vo的确有着大量的对象复制，也是我不希望看到的。

我是这样做的，－当然前提是程序的规模还是比较小。

如果view层只是读取对象，我就把po直接传到view层。如果view层需要改动数据，我就把po的clone传到view层。因为90％的情况只读的。

我补充一下：

以下是摘自程序员杂志中透明的关于这个问题的描述：

很多时候，DTO看上去和实体非常相似，他们的属性和方法可能完全一样，这时你会抱怨，为什么要多做一次转换，直接把实体传递到表示层不是更方便吗？
－－－－－－－－－－－－－－－－－－－－－
顶住诱惑，实体和DTO代表系统中完全不同的角色前者是物理世界在系统中的对应物，后者是展现层对所需要数据的封装，更多的时候，dTO的数据来自多个实体，它能够有效地减少业务层和表示层的交互次数，而起大多数情况下，实体与持久层有着千丝万缕的联系，将他们提供给展示层保露的持久层的策略，而且可能因为实体携带数据库连接而造成无法预知的后果。
－－－－－－－－－－－－－－－－－－－－－

以上所说的DTO就是Data Transfer Object用于将po转化为vo的类。

如果view层只是jsp的话，我觉得“而且可能因为实体携带数据库连接而造成无法预知的后果。”这样的可能性应该没有。
而“更多的时候，dTO的数据来自多个实体”确实是这样的。

但是要显示的数据无非是po内容的组合，如果你要构造你表示层bean，你能很确切的知道你需要显示的数据和它的结构吗？我是很难确定的，我会经常改动界面，比如添加新的数据传递到表示层，如果为了屏蔽po的策略，会引入开发效率的降低，我就放弃前者了。

所以我目前还是选择了直接把po传递到view，如果业务bean里面要对显示的po内容改动，那么就把po科隆一个，然后修改，修改后传递给veiw。大部分时候直接传递po给view。

呵呵，如果以后吃大亏，在反省吧～～～～

如果要增加VO,还要增加DTO，我想还是会增加很大的工作量的。
我们目前做的项目处理方式是这样的，有个业务层：
如果是得到一条记录（一个PO），则将PO中的所有属性用request.setAttribute的方式来传递到jsp中。
如果是多条记录的，则将此得到的多条记录组合成jsp中要显示的字符串，此字符串包含了table tr td等所有显示信息，然后同样用request.setAttribute将此字符串保存，在jsp中获取此字符串直接<%=(String)request.getAttribute("str")%>来显示。
这样是避免了po传到view层，但view层的东西耦合到了业务层，也感觉不好。
不知道有没有人是这样做的？这样做有没有问题？

我个人的认为：即然在jsp页面上可以用useBean为什么就不用呢？你在后台里，用request.setAttribute("str",obj);再到前台jsp页面里进行quest.getAttribute("str");如果数据很大，不是很浪费系统资源吗？不管是服务器端，还是客户端 .如果用useBean的话，一次就把po值读出来，再在页面上转一下，也很快呀！何必，多做这二步呢。当然，如果是数据比较少的话，我觉得还蛮不错的。不知道大家怎么想?

现在问题是使用了struts，如果再在页面中使用useBean就失去了使用struts的意义了。
数据量倒不是问题，因为整个应用是部署在一台机器上的，request.setAttribute("str",obj);只是作个地址的指向而已，并不存在前后台数据的传递。现在这种做法的问题主要是view耦合到了业务层中，也同时失去了利用如dreamweaver等可视化工具来做页面的优势，感觉是用servlet来做显示而不是用jsp，不是很舒服,毕竟用jsp来做view会直观很多。

我现在开发的项目架构的层次是view->action->business logic->dao->po
在business logic层调用dao,可能返回po，这是对返回的po通过转化处理，不让他在Action调用business logic的时候穿透到view上去

我也是这样用的