前言

記得剛工作的時候在專案中看到很多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的理解，如有不對還請看官指正。