应用程序框架实战三十四:数据传输对象(DTO)介绍及各类型实体比较_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > 应用程序框架实战三十四:数据传输对象(DTO)介绍及各类型实体比较

应用程序框架实战三十四:数据传输对象(DTO)介绍及各类型实体比较

 2015/3/31 10:13:24  何镇汐  程序员俱乐部  我要评论(0)
  • 摘要:本文将介绍DDD分层架构中广泛使用的数据传输对象Dto,并且与领域实体Entity,查询实体QueryObject,视图实体ViewModel等几种实体进行比较。领域实体为何不能一统江湖?当你阅读我或其它博主提供的示例代码时,会发现几种类型的实体,这几种实体初步看上去区别不大,只是名称不同,特别在这些示例非常简单的情况下更是如此。你可能会疑惑为何要搞得这么复杂,采用一种实体不是更好?在最理想的情况下,我们只想采用领域实体Entity进行所有的操作。领域实体是领域层的核心
  • 标签:程序 应用 数据 应用程序

  本文将介绍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的长相

  DTO是一个贫血对象,也就是它里面基本没有方法,只有一堆属性,并且所有属性都具有public的getter和setter访问器。

  DTO拥有public的setter访问器,方便的解决了表现层的模型绑定问题。

  由于DTO不执行业务操作,仅用于传递数据,所以不应该定义非常复杂的对象引用关系,这样就避免了循环引用,解决了对象序列化的问题。

DTO的粒度

  DTO可以根据应用需求定义成不同的粒度,在一般情况下,DTO是聚合粒度,也就是说,一个领域层的聚合对应一个DTO,这样做的一个好处是方便对CRUD操作进行抽象以及代码生成。

  界面如果想保持简单,应该尽量一个界面操作一个聚合,将聚合的数据映射到DTO后,传给视图展示。

  对于更加复杂的界面,需要在一个界面操作多个聚合,这种情况下,把需要的全部数据打包到DTO进行操作。

  从以上介绍中,你应该了解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,
            };
        }
    }
}

 

DTO 与 ViewModel比较

  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为我解决了如下几个问题:

  • 领域实体在表现层进行模型绑定时可能失败
  • 序列化领域实体可能失败
  • 领域实体无法应对多客户端应用需求,通过创建多套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/

 

发表评论
用户名: 匿名