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

我只是开个玩笑，说不上什么排斥感，你多心了。

其实你说的我都明白，但是你还是太拘泥于概念了，PO送到表示层就不是PO了，而是VO了(确切得说，是detached PO)。那又如何？你把它当VO用不就行了吗？我用绝对两个字是为了更醒目些，其实呢，大部分WEB应用，使用OpenSessionInView模式，都可以把PO直接传到表现层，而不需要DTO(不包括EJB)。

投票什么的就算了吧，建议你去透明的blog看看
有点开窍了

再去potian的blog看看
DTO，我需要吗？

Open your mind，就知道我说的有没有道理了。:)

呵呵，楼上，如果是讨论一个具体的东西，我想你说的没有错。我不是拘于概念，只是你的表达会对很多刚刚入门的进行误导。
   PO和VO是怎么来的？有什么区别？其实理解了这个，也就理解了问题的实质，PO只是数据库实体（或者说是物理数据模型）的一种对象反映，而VO是业务实体（或者说概念模型）的一种抽象反映。PO在属性上可以和VO相等么？当然是可以的啊。当一个业务实体可以用一个物理实体表示的时候，那么PO和VO在属性层次上其实就是一样的。
    简单地讲吧，一个订单的业务实体，它包括货币，客户信息等，它就不能用一个业务实体所描述，那么，对应的VO是不同于PO的；而其中的货币信息，VO和PO在属性上完全就是一样，不存在其他的差别，这个时候，我们用和PO在属性上相同的java bean当然可以代替（注意，它不是什么PO，没有持久性，何来PO的概念）。
    另外，我们如果不用VO，或者说不用反映业务实体的值对象，而用反映物理实体的对象，会带来什么呢？最大的问题就是会有三种：一、当一个业务实体需要多个物理实体反映的时候，客户端显示一个业务实体就会需要多次的数据库访问（简单地讲就是不用视图，而用多次单表访问）；二、当一个业务实体远小于一个物理实体的时候，同时需要一次性装载一定数量的时候，就会出现过多的数据垃圾与网络传输负载；三、当需要对后台物理存储或者物理实体进行改动的时候，必然就会影响到表示层，因为没有一个中间的过程将其隔离。
    VO的出现目的是让客户（包括人和系统）了解的业务实体与后台实际存储的物理实体相隔离，降低各层之间的耦合性。其次，充分合理的提高系统的性能，降低调用的复杂度。
    如果，看了我上面这些，楼上还是认为某些人提出的将实体从持久层传到表现层的话，我真是无话可说了。为了简单，采用JSP直接访问数据库更好。

刚刚看来楼上留下的网址，看了那篇《DTO，我需要么》的文章。
    其实，它符合了非程序员提出的软件以用为本。他强调了一个情况，“因此，我已经再也不愿意为了一个永远不可能分布的程序去实现这么一大堆DTO，结果就是我的代码减少到50%左右，我的所有代码可以非常简洁、OO的使用。”在一个项目周期短，经验不够，同时，后续的可维护性不高的时候，采用文中所说的也未尝不可。
    我在这里想谈的，不是说这样简单小巧的系统是否改用繁杂的架构，那样没有什么意义。中国为什么缺乏好的架构设计师，因为中国太多的程序员只是将眼光聚焦在一个房间的装修或者一栋小楼的建造，而不去领会构造一个大型建筑的思维与境界；盲目地追求使用各种开源的工具与框架，什么地方都搬用，而不去领会工具与框架所蕴涵的思想的内涵与精髓与其带来的革命。
    在讨论框架、架构这类问题的时候，我希望所交流所面对的，不应该只是一个普通程序员的出发角度。
    软件以用为本，但不是以用则以。
    我也许话说大了，我同样也只是这批人中的一个普通人，我也在努力地进行跳跃...............
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
      刚刚写了一篇BLOG,有兴趣的朋友可以看看

说得好！
其实系统中最最稳定的就是po，他是外部世界实体的真实抽象，他变动的唯一前提是外部实体发生变化。
不但要把po传递到表现层，还要把po保留下来再从表现层传回到业务层最后回归持久层，这样形成一个环多优雅。

PO，VO，DTO，分那么多xxO，只会增加Line Of Code，把系统复杂化，增加理解、维护系统的困难度，用Domain Object串起来就是最好的re-use。

关于多层架构中是否需要DTO来转化，hibernate官方论坛上在2月份的时候有过一个蛮长的讨论，有兴趣的大家可以用DTO做keyword去那里搜索一下。Gavin King也是不建议使用DTO，我前面提到的那个Link （ http://www.hibernate.org/hib_docs/online/atljug04_presentation/hibernate_atljug2004.pdf ），是他在1月份时的一个Presentation，提到了DTOs are evil，Hibernate的提供Detached Object 和 Version , UnSaved Value可以用来解决这方面的问题。


从新的EJB3.0规范看，由于采用POJO的模型，我们不需要再implement任何的javax.ejb interface，有Detached Object支持，DTO将会彻底地变成反模式。

1. 会不会误导初学者？

我认为不会，相反，告诉他们还有这么一条路可走，让他们自己在工作实践中去摸索体会，比一开始就告诉别人"我说的才是儒学正宗，你已经走了弯路"要好。

2. 为了简单，采用JSP直接访问数据库更好。

简单也好，分层也好，都有一个前提，就是合理可行。你说，你那么喜欢简单，那就用JSP直接访问数据库好了。我说，你那么喜欢架构，怎么不叠它个十七八层？其实这两句话都是non sense。我们要寻找的是这两个极端之间的平衡，前提是合理可行，标准呢，只要能满足你当前的需要就好了。以前有人打过个比喻，如果你要建的是个狗窝，就没有必要按照摩天大楼的架势打地基了，余深以为然。

3. 那也许是一个好的web应用，但绝对称不上是一个多层架构应用的

呵呵，既然是软件以用为本，那么一个好的应用就已经足够了，管它是不是多层架构应用呢？所以说，不要为架构而架构，为耦合而耦合，在开始架构之前，评估一下你的项目，到底是什么需求。有多大的饭量，就用多大的碗，否则多盛来的，也只是浪费而已。

其实大家说得都好，从理论上讲，都有道理，只不过，缺乏代码的辅助，所以，我很希望看到你们在项目中的实践，“dont talk more, just give me the code”，呵呵。

题外话：最近再看《程序员的修炼之道》感觉不错，推荐

    居然会有这样的帖子，把PO当作外部世界实体的真实抽象，还形成所谓的环，我真想说，MVC，TMD你白理解了！我只有一个字，苦～～～～～～～～～～～～～。
   不怨人家不能学，不怨自己不愿说，只是对于丝毫不去思考的人，真无话可说了。  robbin，删掉我这个帖子中的所有回复吧，我不想讨论这个话题了。

     这便是角度，位置不同，角度不同，看待问题的出发点也不同。等你有一天负责公司的技术架构，负责一个整体框架的思考的时候，你会明白的。

Open your mind，共勉。