开贴再论为何DTO在大型架构里是必须的。

构建DTO的工作绝对不是业务逻辑的一部分。
因为你的DTO是给应用层用的。如果你在业务逻辑中组装DTO,岂不是业务层要
依赖应用层？

集群和DTO没有任何关系，完全赞同。我说需要集群的意思是因为应用规模太大。集群是一种比较好的J2EE扩充容量的方式。


在电信和银行分布式是否必须，不是我说了算的。这个是客户说了算的。试想比如你的客户资料作为一个平台，那么多周边系统需要调用它，你不分布式怎么能行呢？


我们在第一个产品用Hibernate的时候的确就是要什么就拿什么。开始不觉得有何不妥。后来就发现由于某些业务领域的相似性，这样做简直就是让高级程序员做体力活。现在要搞出这么事情，正是要解决这个问题。
多加一层的好处在于：
1、数据持久策略可以动态替换（不但是ORM，你也可以用传统的JDBC）；
2、解耦；
3、更低的工作量；
4、更好的可维护性；


正式因为构建DTO应该是业务逻辑直接关心的。才把它移出去统一用一个架构完成。业务层不会依赖应用层，而是应用层是根据业务来展示的。

这样吧，你还是把你项目中那些遇到的问题代码简化一下，改写一下贴出来大家分析好了。

:wink: 孺子不可教也...... 嘿嘿

那就以一个查询为例吧：

之前的代码：

 session = sessionFactory.getSession();; 
CustBaseInfoPO baseInfoPO =  hs.queryByTemplate(vo);;

CustInfoVO custInfoVO = new CustInfoVO();;
//这里写一堆get，set方法来赋值给custInfoVO 
……

GroupInfoPO groupInfoPO = custInfoVO.getGroupInfoPO();;
//这里又写一堆get，set方法来赋值给custInfoVO 
……

//类似的代码根据业务可能会有很多。

//最后，所有的业务属性提取完毕，把custInfoVO 返回前端
return custInfoVO ;

如果采用DTO模式，代码就非常简单了。我们需要配置文件定义如下：

<vopo-mapping> 
        <vo class="org.sunny.vo.CustsInfoVO"> 
                <po name="CustBasePO" class="org.sunny.po.CustBasePO" table="t_ptcl_custinfo"> 
                        <property name="custid"/> 
                        <property name="custname"/> 
                        <one-to-many voproperty="custid" poproperty="custid"/> 
                </po> 
                <po name="CustGroupPO" class="org.sunny.po.CustGroupPO" table="t_ptcl_groupinfo"> 
                        <property name="custid"/> 
                        <property name="groupid"/> 
                </po>                                
                <relationid name="custid" property="custid"/> 
        </vo> 
        <vo class="org.sunny.vo.UserInfoVO"> 
                <po name="UesrInfoPO" class="org.sunny.po.UserInfoPO"/> 
        </vo>        
</vopo-mapping>

代码就这样写：

session = sessionFactory.getSession();; 
return  hs.queryByTemplate(vo);;

大家看到了，代码的简洁性是不言而喻的。如果业务发生变化，也只需要修改配置文件，而不用修改你的代码。业务逻辑的代码写在SLSB里，意味着你需要修改代码－>编译->部署等等费时的操作。但是用户的业务很多时候是不允许停的。

如果是多人开发一个一定规模的程序，我是支持dto的，特别是dto对于swing/swt的富客户端就更需要了，比如说一个crm里的Lead：
前台开发人员看到的接口（包含swt远程接口开发人员和jsp开发人员），这个接口还是实现事务／验证的好地方：

public interface LeadService {
    public String create(String leadXml);;
    public void retrieve(String leadId);;
    public void update(String leadXml);;
    public void delete(String leadId);;
    public void accept(String leadId);;
    ...
}

这个接口是很薄的一层，没有业务罗辑，只是把请求直接转发给DO。
比如accept方法是这样：

public LeadService::accept(String leadId, int status); {
    Lead lead = CallContext.current();.getSession();.load(Lead.class, String leadId);;
    lead.accept(status);;
}

对于对象错终复杂，盘根错节时，你还要swt界面开发人员理解你的类就太麻烦了，且这样也能解偶和利于并行开发。

没错 我也觉得 从不同层次之间解耦的方面来考虑, DTO有它存在的必要.

基于对象的表示法已经是最接近人的思想了，还想怎样，把领域对象构造图给swt开发人员look,阿猫啊狗对象容易被记住。

另外这个贴已经不明白讲什么了，就别再把分布式里使用dto的必要性进行重复说明了。
关键作者说明白在一个具体的处理过程中，处理流程是怎样的，最好不要出现dto,vo,po这样的字眼!这样才有继续讨论的基础。

to:tuskrabbit 怡情居－獠牙兔子

就你举的这个例子,偶无法看出在这里再包一层只是减轻了set,get操作的
动作,如果仅仅是减轻set,get操作，现在有太多的方法来解决了,何苦还
要在配置中解决呢？况且这些配置又要在startup的时候装载到内存(虽然
现在内存基本无须考虑),但是我是尽量避免无用的东西扔到内存里的...

我想在配置里解决的是PO字段和VO字段数据结构转换的过程,但这一过程
又不会象你举的例子那样简单..

能举个更好的例子吗？