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

To pufan:

看看透明的这篇blog和后面的评论：
http://www.blogdriver.com/showBlog.do?diaryID=166013

to sayor:
确实可以这样吧，呵呵，不过我估计这取决于架构，如果你有明确的facade，应该可以用接口限制对象在客户端的可见性，这时我估计应该有两个接口，一个是针对客户端的，一个针对服务器端，当然目的不同。当没有facade的时候（因为有了facade也许很多地方就抵消了domain model的好处），就会直接把整个接口暴露出来，也许此时不一定非常需要单独一个客户端接口。

不过总的来说通过接口引用domain object不是hibernate/spring的提倡方式，因为在客户端你不能直接new()对象了，要通过创建型模式。而且把domain object提升为组件之后也要考虑spring那样的框架遇到的麻烦估计不少,需要自己定制框架？没做过，不好说。

to pufan

把CRUD方法放在domain里面是hibernate模式里面的一个吧，如果你的domain是直接被客户端引用，我觉得这样可以简化很多操作，避开过多的service调用，如果session和tx是在客户端管理的话就更好了。当然如果直接继承的话domain就耦合在hibernate上面了，可以考虑代理给DAO，或者用AOP introduction/mixin（当然这样可能过于通用，反而模糊了语义）...

to ultra兄,

在web tier使用了MVC模式的情况中，domain model对于controller来说可以暴露，我觉得这样做的坏处比好处要少。因为，将domain model隐藏在一个facade后面，这样是间接的暴露了接口，这样做要么使用DTO，要么将domain object的接口作为DTO，然后作为facade的参数和返回值。无论何种方式，相对直接将domain object暴露给controller相比都增加了不少代码量。感觉facade的作用还是主要体现在减少远程访问的次数上。而且在domain model的客户端在本地的情况下，并不需要DTO或者其他手段来将客户端和服务器端的jar包做区分。其次，domain model在presentation则应该得到隔离，但这样的隔离也是针对其业务逻辑的隔离，使得商业逻辑不要扩散到表示层。因此，我认为在页面上可以考虑只暴露需要的domain model的属性及其getter,setter。当然这样做也许也没有太大的必要。无论如何view依赖于presentation,presentation依赖于domain model，这样的依赖在架构上是始终存在的。以上所说的domain model是使用POJO来实现，如果使用EB，则有很多问题是有定论了，但EB在实现复杂的domain model时，比如有继承，策略模式时看来是比较困难的，并且EB对容器的依赖使得domain model对环境有了依赖。是否将domain model传到view是有很多地方需要考量的。

    这是一个非常好的方法，在J2EE核心模式中关于值对象工厂模式也就是这样的方式，只不过将它拓展到所有domain对象中，从而可以降低对象的数量。
  其实，它还有另外一层作用，大家在做权限控制的时候，也许一般只是做到功能级的（我曾经做到过数据行级，也就是对象级），另外做到数据列级的权限控制是很难的，我一直一来都琢磨这个思路，其实通过domain数据域接口就完全可以实现了。

    同你一样，对于这一点，我也是反对的，如果domain对象加入这样的功能，那么就把数据的描述和数据的处理操作聚合了。domain（也就是我们常常讨论的PO.VO.BO.DTO），它只是通信的介质（数据传输的介质）和概念的扩展描述（都是来自于概念模型的扩展），不应该封装逻辑操作的

这个帖子看的我晕了。

上面的话不是我写的，你引用错了吧 ；）。
其实并不是在domain model中加入数据库的操作，而是在其中加入业务逻辑。数据持久化还是通过ORM来实现。
另外，domain model指得是对商业事务的抽象，比如说订单的管理，那么订单order就是一个domain object它包含了订单的数据以及和订单相关的方法。domain model是一种架构模式，它是和transaction script相对应的。transaction script中一般会有经常说的Po来表示业务领域的数据以及专门的封装业务逻辑的一个service类，比如说一个slsb。而如果采用domain model的话，将把po和service类合在一起。即一个类既有行为也有属性，这是完全OO的做法。而transaction script中的service类的方法往往是一个过程，是面向过程的做法。transaction script最大的坏处是会有很多重复的代码产生，比如在处理订单的业务中，可能有很多的代码很相似，但由于这些相似的代码处于不同的处理流程中，所以这些代码会在不同的transaction script中出现而导致重复。利用domain model则避免了这种情况。

    何老板，呵呵，别说你，我也是被搞晕了，反正是什么都扯什么都谈

继续扯，个人挺爱看。

可能楼主的问题不是三言两语就可以讲清楚的，所有扯得远了点，呵呵。