前言

记得刚工作的时候在项目中看到很多DTO的声明和定义，当时不太明白Dto和ViewModel的区别，随着工作经验的增加，再回首，偶有新感悟，写下随笔，算是对当时自己疑问的回应。

正文

DTO

Data Transfer Object 数据传输对象
DTO常见于接口输入参数，可以看做是接口传入参数的封装对象，同时参数中和数据库实体模型有一部分交集；比如需要提供一个用于修改一个学生类的姓名的API，那就可以定义一个StudentDTO，里面封装一个主键字段和姓名字段，将此DTO作为接口的传入参数。在比较简单的操作中，封装DTO体现不出优势，但是当项目代码达到一定规模后，封装DTO可以规范代码的结构，便于项目的维护。

ViewModel

视图模型
ViewModel 常见于MVC中 Contoller 返回的实体模型的命名。是对返回的数据库实体模型的封装，同时参数中和数据库实体模型有一部分交集。其思想是为了封装接口暴露的对象，很像数据库开发中视图的使用场景。避免暴露部分字段，只提供需要的部分。

    [Table("Student")]
    public class Student
    {
        public string StuNo { get; set; }
        public string Name { get; set; }
        public DateTime? CreateTime { get; set; }
        public DateTime? UpdateTime { get; set; }
    }

    [Table("Class")]
    public class Classes
    {
        public string ClassNo { get; set; }
        public string Name { get; set; }
        public  DateTime? CreateTime { get; set; }
        public  DateTime? UpdateTime { get; set; }
    }

    public class StudentViewModel
    {
        public string StuNo { get; set; }
        public string Name { get; set; }

 
    }

    public class ClassesViewModel
    {
        public string ClassNo { get; set; }
        public string Name { get; set; }

        public List<StudentViewModel> Students { get; set; }

        public ClassesViewModel()
        {
            Students = new List<StudentViewModel>();
        }
    }

通过这种方式的封装，使代码和架构设计更规范。但这样在引入了ORM的项目中会带来一个问题，就是数据库基类定义的公共方法比如Get SelectById(TPrimaryKey id)方法拿到的是Entity Model而非ViewModel，由Model向ViewModel转化需要用代码处理，当业务代码足够多或者Entity的字段很多的时候，这个转化的代码带来的工作量是很大的并且不好维护。这时候就引入了OOM（Object-Object-Mapping）框架，通过OOM框架提供的功能可以省去转化的逻辑代码，从而减少重复的工作量

结语

以上就是我关于DTO和ViewModel的理解，如有不对还请看官指正。

浅谈ViewModel和DTO