为什么我的程序传递DTO

我来把它变成大白话，“调用者就不能直接操作DomainObject了”，这是好事还是坏事，确实是个问题。


合适就好。 

可能作者说的domain Object是包含了业务逻辑方法的Object.

在分布式环境中引入DTO还是很有必要的，我们假设这样的应用场景：
Client: SWT/Swing
Serverside:Spring + hibernate
使用RMI协议交换数据，如果直接将hibernate domain object传递给客户端，那么就会有问题产生：一方面客户端需要展现的内容和domain object有出入，如查询、报表统计类；另外一个方面domain object的lazy load如何处理呢？难道将所有的lazy关闭，即使是使用JDBC使用持久层也是存在这个问题的。

但是在基于web的项目开发中，我觉得引入DTO对象增加了复杂性，没有必要。其实DTO是存在的，只是这个DTO对象可以使用domain object替换，它只存在概念中。

在项目使用编写Assembler是发现有个问题，不知道如何处理比较合适？

DTO和Domain Object应该怎么设计呢？

如有两个对象：项目分类(FeeType)和项目(FeeItem)，它们之间是一对多的关系，即一个FeeType可能包含多个FeeItem，一个FeeItem属于某个FeeType。接下来的问题是如何设计DTO对象呢？
假设我的FeeItemDTO是这样：

public class FeeTypeDTO implements java.io.Serializable{

	private static final long serialVersionUID = 5462251365674063841L;
	
	private Integer feeTypeNum;

	private String feeTypeCode;

	private String feeTypeName;

	private String feeTypeMemo;
。。。
}

那么如果客户端传递这样的DTO对象时，我怎么装配我的Domain Object呢？新建一个FeeType对象，只设置Id？


假设我的FeeItemDTO是这样：

public class FeeTypeDTO implements java.io.Serializable{

	private static final long serialVersionUID = 5462251365674063841L;
	
	private FeeTypeDTO feeTypeDTO;

	private String feeTypeCode;

	private String feeTypeName;

	private String feeTypeMemo;

}

直接使用DTO引用DTO的方式，上面第一种设计中装配问题倒是不存在了，但是客户端发问了：为什么我保存一个FeeItem，要给你设置这么多不需要保存的数据呢？


大家在设计中使用哪种方式处理呢？

看得不是很明白。
不能建立FeeTypeInfo和FeeItemInfo两个DTO麽？

这个问题，俺还需要比较所有可能的方案。

首先，让我们假设在不需要Remoting的情况下，传递DomainObject是合理的，看看能得到什么结论。
两个项目，一个只需要支持经典WEB应用，另一个只支持RCP应用。
那么，一个使用传递DomainObject的Service接口，一个使用传递DTO的RemoteFacade/Service接口，就是合理的。
现在，分别增加对另一种应用的支持。
传递DomainObject的Service接口，在其上需要封装为RemoteFacade接口。
传递DTO的接口，可以直接使用。
区别是，前面的一种演化多了一层接口，并且不同的应用要面对不同的接口。

如果，在最初，项目就有两种应用需要支持，那么Remote不可避免，所以组装工作不再是额外的工作。使用传递DTO，RemoteFacade/Service的接口，就是合理的。

因此，结论就是，在传递DomainObject是合理的前提下，传递DomainObject的Service接口，在目前只需要支持经典WEB的应用并且不会有第二种应用时，是合理的。其余的情况，传递基于DTO的Service接口才合理。

关于Service层传递DomainObject是否合理的假设，在我看来，只适合于简单的项目，这与只有一种应用是匹配的。复杂的项目意味着，人多（这样信息隐藏对于前台/后台开发人员的划分，是有益），应用多（不同的应用共享Servie接口，也很美观和简洁），业务视图同领域视图差别变大。