本文将介绍DDD分层架构中广泛使用的数据传输对象Dto，并且与领域实体Entity，查询实体QueryObject，视图实体ViewModel等几种实体进行比较。
当你阅读我或其它博主提供的示例代码时，会发现几种类型的实体，这几种实体初步看上去区别不大，只是名称不同，特别在这些示例非常简单的情况下更是如此。你可能会疑惑为何要搞得这么复杂，采用一种实体不是更好？
在最理想的情况下，我们只想采用领域实体Entity进行所有的操作。
领域实体是领域层的核心，是业务逻辑的主要放置场所。换句话说，领域实体中包含了大量业务逻辑方法。
如果领域实体中的属性都包含getter和setter，并且所有属性都是public的，那么，使用这个Entity的程序员可能会绕过业务方法，直接操作属性进行赋值。
为属性直接赋值，是面向数据的过程式思维，而调用方法是面向对象的方式，这也是领域模型的核心所在。
所以为了强制实施业务规则，必须把业务方法操作过的属性的setter访问器隐藏起来，否则这个方法不会有人调用。
当领域实体某些属性的setter被隐藏后，直接在表现层操作领域实体将变得困难，因为Mvc或Wpf的模型绑定只能操作public的属性。
哪怕你的系统没有使用分布式，比如只是一个Mvc网站，但由于前端要求越来越高，客户端很多时候需要通过ajax与服务端进行交流，一般采用json格式传递数据，这就要求你的实体能够序列化。
对领域实体进行序列化，首先需要考虑的问题是，可能序列化一个较大的对象图，从而导致不必要的开销。
领域实体一般包含导航属性指向其它领域实体，其它的领域实体可能包含更多导航属性，从而组成一个对象图。如果采用Serializable特性进行序列化，并且没有指定其它序列化选项，可能导致把一个庞大的对象图序列化并进行网络传输。
另一个问题是，复杂的领域实体可能包含循环引用，从而导致序列化失败。
对于序列化，一个更好的选择是采用DataContract特性，被DataContract修饰过的类成员，不会被自动序列化，必须在成员上明确指定DataMember特性。
DataMember在一定程度上可以缓解上述问题，比如减少需要序列化的数据，不序列化循环引用的对象等，但无法从根本上解决问题。
对于不同的客户端，可能需要的数据和格式不同，这属于应用层需求，而领域实体只有一个，在领域实体上通过标记DataMember进行序列化费力不讨好，无法满足复杂的应用需求。
哪怕你只有一个Mvc网站，如果页面上需要显示一些领域实体不存在的数据，你根据这个需求，直接在领域实体上增加属性是非常糟糕的做法，会严重污染你的领域模型，将大大降低领域实体的复用能力。
从以上可以看出，对于一个比较复杂的系统，单凭领域实体很难完成任务，将太多的职责强加到领域实体上，会导致领域实体严重变形。
数据传输对象，即Data Transfer Object，简称DTO。
一个为了减少方法调用次数而在进程间传输数据的对象，《企业应用架构模式》如是说。
可以看出，DTO用于分布式环境，主要用来解决分布式调用的性能问题。同一进程内的对象调用，速度是非常快的，但跨进程调用，甚至跨网络调用，性能下降N个数量级。为了提升性能，需要减少调用次数，这就要求把多次调用的结果打包成一个对象，在一次调用中返回尽量多的数据。
上面是DTO的原始含义，下面来看看我的山寨用法。
虽然我也取名为DTO，但我的动机并不完全是一次打包更多数据来提升性能，而是解决上面提到的几个问题，当然它们之间有一定关系，可以看作一种变种用法。
DTO是一个贫血对象，也就是它里面基本没有方法，只有一堆属性，并且所有属性都具有public的getter和setter访问器。
DTO拥有public的setter访问器，方便的解决了表现层的模型绑定问题。
由于DTO不执行业务操作，仅用于传递数据，所以不应该定义非常复杂的对象引用关系，这样就避免了循环引用，解决了对象序列化的问题。
DTO可以根据应用需求定义成不同的粒度，在一般情况下，DTO是聚合粒度，也就是说，一个领域层的聚合对应一个DTO，这样做的一个好处是方便对CRUD操作进行抽象以及代码生成。
界面如果想保持简单，应该尽量一个界面操作一个聚合，将聚合的数据映射到DTO后，传给视图展示。
对于更加复杂的界面，需要在一个界面操作多个聚合，这种情况下，把需要的全部数据打包到DTO进行操作。
从以上介绍中，你应该了解DTO不能理解为单表操作，它可以包含你需要的全部数据。
DTO处于应用层，在表现层与领域层之间传递数据。
DTO由应用层服务使用，应用层服务从仓储中获得聚合，并调用DTO转换器将聚合映射为DTO，再将DTO传递给表现层。
关于应用层服务，后续再专门介绍。
聚合与DTO的转换，看上去是一个简单问题，在聚合与DTO几乎完全一致的情况下，采用映射组件将非常省力。很多人采用AutoMapper，但它的性能稍微差了点，EmitMapper是更好的选择，性能接近硬编码。
当DTO与聚合显著不同时，我发现手工编码更加清晰高效。我采用代码生成器创建出一个代码基础，在有个性化需求时，手工修改映射代码。
我总是采用一个静态类来扩展DTO和聚合，为它们添加相关的转换方法。
using Biz.Security.Domains.Models;
using Util;
namespace Biz.Security.Services.Dtos {
/// <summary>
/// 应用程序数据传输对象扩展
/// </summary>
public static class ApplicationDtoExtension {
/// <summary>
/// 转换为应用程序实体
/// </summary>
/// <param name="dto">应用程序数据传输对象</param>
public static Application ToEntity( this ApplicationDto dto ) {
return new Application( dto.Id.ToGuid() ) {
Code = dto.Code,
Name = dto.Name,
Note = dto.Note,
Enabled = dto.Enabled,
CreateTime = dto.CreateTime,
Version = dto.Version,
};
}
/// <summary>
/// 转换为应用程序数据传输对象
/// </summary>
/// <param name="entity">应用程序实体</param>
public static ApplicationDto ToDto( this Application entity ) {
return new ApplicationDto {
Id = entity.Id.ToString(),
Code = entity.Code,
Name = entity.Name,
Note = entity.Note,
Enabled = entity.Enabled,
CreateTime = entity.CreateTime,
Version = entity.Version,
};
}
}
}
ViewModel是为特定视图专门定义的实体对象，专为该视图服务。
对于WPF，ViewModel是必须的，用来支持MVVM模式进行双向绑定。
那么MVC呢，一定需要它吗？
由于采用了DTO，在一般情况下，我都把这个DTO当作ViewModel来使用。如果界面上需要某个属性，我会直接添加到DTO上。
一个例外是，如果MVC的界面非常复杂，我感觉把大量的垃圾属性加到DTO上不合适，就会创建专门的ViewModel。
查询实体这个说法，是我乱取的，估计你在其它地方也没有听说过。使用它的原因，是用来配合我的查询组件一起工作。
我前面已经介绍过查询相关的内容，核心思想是通过判断一个可空属性，自动完成空值判断，这是一个强大的特性，帮助你免于编写大量杂乱无章的判断。
查询实体的基本特征就是所有属性必须可空，并且它足够简单，不会拥有集合那样的子对象，所有属性都是扁平化的。
通过传递查询实体，表现层可以做到尽量简单，由于表现层支持模型绑定，甚至不需要代码，省力是我搭建框架的一个基本出发点。
当然查询实体只支持简单查询，不支持灵活的动态查询，比如让客户设置查询运算符等，暂时没有这方面的需求，如果后续有需求，会扩展一个出来。
查询实体示例：
using System.ComponentModel.DataAnnotations;
using Util;
using Util.Domains.Repositories;
namespace Biz.Security.Domains.Queries {
/// <summary>
/// 应用程序查询实体
/// </summary>
public class ApplicationQuery : Pager {
/// <summary>
/// 应用程序编号
/// </summary>
[Display( Name = "应用程序编号" )]
public System.Guid? ApplicationId { get; set; }
private string _code = string.Empty;
/// <summary>
/// 应用程序编码
/// </summary>
[Display( Name = "应用程序编码" )]
public string Code {
get { return _code == null ? string.Empty : _code.Trim(); }
set { _code = value; }
}
private string _name = string.Empty;
/// <summary>
/// 应用程序名称
/// </summary>
[Display( Name = "应用程序名称" )]
public string Name {
get { return _name == null ? string.Empty : _name.Trim(); }
set { _name = value; }
}
private string _note = string.Empty;
/// <summary>
/// 备注
/// </summary>
[Display( Name = "备注" )]
public string Note {
get { return _note == null ? string.Empty : _note.Trim(); }
set { _note = value; }
}
/// <summary>
/// 启用
/// </summary>
[Display( Name = "启用" )]
public bool? Enabled { get; set; }
/// <summary>
/// 起始创建时间
/// </summary>
[Display( Name = "起始创建时间" )]
public System.DateTime? BeginCreateTime { get; set; }
/// <summary>
/// 结束创建时间
/// </summary>
[Display( Name = "结束创建时间" )]
public System.DateTime? EndCreateTime { get; set; }
/// <summary>
/// 添加描述
/// </summary>
protected override void AddDescriptions() {
base.AddDescriptions();
AddDescription( "应用程序编号", ApplicationId );
AddDescription( "应用程序编码", Code );
AddDescription( "应用程序名称", Name );
AddDescription( "备注", Note );
AddDescription( "启用", Enabled.Description() );
AddDescription( "起始创建时间", BeginCreateTime );
AddDescription( "结束创建时间", EndCreateTime );
}
}
}
最后来总结一下：
1. 领域实体是系统的中心，是业务逻辑的主要放置场所，应该尽量关闭业务逻辑操作的属性，以避免有人能绕过你的方法直接操作数据。
2. DTO是数据传输对象，原义是用来在分布式系统中一次传输更多数据，以减少调用次数，提升性能。
3. 我的DTO用法离原义相去甚远，只是借用了DTO的名词，属于变种。DTO为我解决了如下几个问题：
4. DTO是包含大量属性，没有方法的贫血实体，所有属性都开放getter和setter，以方便模型绑定和序列化。
5. DTO一般情况下是聚合去除方法后的模样，主要好处是方便抽象CRUD及代码生成。
6. DTO位于应用层，由应用层服务操作它。
7. DTO的映射可以采用映射组件，也可以代码生成方便随时修改，以你觉得方便为主。
8. 仅在WPF环境下才需要为每个视图创建一个对应的ViewModel，MVC一般使用DTO即可，仅为复杂界面创建ViewModel。
9. 查询实体是为了配合查询组件引入的构造，目的是帮助查询组件完成空值判断，并且简化表现层的调用。
本文分享了我在几个构造类型上的认识和经验，希望大家积极讨论，更希望高手能指正我的不足，帮助我与大家一起进步。
.Net应用程序框架交流QQ群: 386092459，欢迎有兴趣的朋友加入讨论。
.Net Easyui开发交流QQ群（本群仅限Easyui开发者，非Easyui开发者勿进）：157809322
谢谢大家的持续关注，我的博客地址：http://www.cnblogs.com/xiadao521/
相关文章
