一：什么是領域模型（Domain Model）

         1，Entities

         2，Value Objects

         3，Relations

　　二：只談驗證（Validation）——三種常見的做法

         1，Constructor/Method based Validation

         2，Validate() Method

         3，Validation Services

         4，Validation Configuration

　　一：什么是領域模型（Domain Model）

　　我們可以在概念層次認為Domain Model就是在大的領域邊界中的，可以用基于離散的思想來限定出的，承載“數據”和“關系”的小邊界（個人給的定義，僅供參考）。定義中蘊含著這樣一層意思：所謂模型乃是我們限定出的用于解決問題的承載著“數據”與“關系”的“問題邊界”，也就是Model不一定跟現實中的真實物理對象一一對應，雖然大都一一對應。領域大邊界由Model小邊界來明確，Model小邊界需要由領域大邊界來給限定出問題的范圍（因為宇宙是無窮的開放的，除了那個終極規律外的任何規律都是有適用范圍的，不限定出范圍就會寸步難行，無法認識任何問題了）。

　　領域模型承載的數據可以分為兩個類別：Entities和Value Objects。Model中的數據依照一定“規則”模擬出一個有機的問題模型，這個“規則”約等于Relations。

　　1， Entity是這樣的數據，在它的生命周期中需要一個標識（Identity）。在Domain Model中（注意這里的Model是在一個限定的領域中的）如果某條數據脫離了這個標識就沒有了意義的話，那么這樣的數據就是該Domain Model的Entities類別的數據了。比如在cnblogs的系統中，每一個BlogSite都有一個BlogTitle，但是這個BlogTitle是可以修改的，當我修改了我的BlogSite的BlogTile后我卻依然能夠通過“www.cnblogs.com/xuefly”訪問到，這里可以說“www.cnblogs.com/xuefly”就是我的blog的標識了。如果沒有這個標識存在的話，那么BlogTitle在空間中的存在也就沒有了意義（當BlogTitle與BlogSite脫離后BlogTitle就變成了“字符串”，而在Blog領域中“字符串”是沒有意義的）。像BlogTitle這樣的數據就是屬于BlogSite模型的的Entitys類別的數據，我們把這樣的數據交給BlogSite來驗證的話是合理的。比如當我們修改自己的BlogSite的BlogTile中包含敏感的非法字符時或者長度超過了一定限度時，修改就不會保存成功，這里的驗證就該是由BlogSite本身來完成的。

　　2， Value Objects是這樣的數據：它的存在不需要標識。存在就是要有意義，還是在cnblogs的系統中，每個BlogSite都會有博主（BlogOwner），因為我們的BlogSite是單用戶的所以在BlogSite中應該會有一個BlogUser:Person類型的屬性，我們假設這個屬性被命名為BlogOwner。

　　BlogOwner是一個BlogUser類型的對象，BlogUser類型對象的存在不依賴于BlogSite的存在，也就是即使沒有BlogSite的話這個被指向了BlogSite.BlogOwner的BlogUser類型的對象依然有存在的意義（是否可以這樣理解，BlogUser是一個Person，而Person在Blog領域中是具有意義的）。這里的BlogOwner就可以歸為BlogSite的Value Object類別的數據了。我們看到BlogSite有一個ID標識，這個ID標識是提供給BlogTitle這樣的BlogSite的Entitys類別的數據的，并不是提供給BlogOwner的。再進一步說明就是：在一個BlogSite類型的對象blogSite1中，blogSite1的BlogOwner屬性值原來指向user1，而現在我們把blogSite1.BlogOwner指向null，這時user1失去了與blogSite1的聯系，然而user1卻在整個Blog領域中依舊具有實際的意義，因為在Blog領域中必須有用戶這個概念（BlogUser Class），user1是一個用戶，user1在blog領域中依舊有意義。而BlogTitle就不同了（blogSite1.BlogTitle = blogTitle1），如果我們把blogSite1.BlogTitle指向null的話，BlogTitle1同樣與blogSite1脫離了關系，這個時候blogTitle1由“博客標題”變成了“字符串”，blogTitle1是個字符串，它在Blog領域中沒有意義。BlogOwner屬于BlogSite的Value Objects類別的數據，BlogOwner的數據應交由BlogUser模型來驗證，不應由BlogSite模型來驗證。與BlogSite一樣BlogUser.Name，BlogUser.LoginID，BlogUser.Password屬于BlogUser模型的Entitys類別的數據。

　　3，關系（Relations）

　　……

　　二，只談驗證（Domain Model Validation）

　　業務規則要求我們的Domain Model必須滿足某些約束，比如BlogSite的BlogTitle的長度不能大于等于255個字符等，這就是業務規則。如果說對BlogTitle的長度進行約束貌似還有點不怎么說的通的話，那么在Blog領域中業務規則要求BlogUser類型的對象的Age屬性不能小于等于零就是無可厚非的了。正是這些被約束的數據組成了Domain Model，通過這些約束，低級的數據（基本數據類型）被我們組織成了更高一級的復雜類型的數據——Domain Model Class，然后領域中的所有Domain Model交織起來最終又詮釋了整個領域。我們認為：沒有邊界的宇宙中的每一個概念都是被約束出來的，無論是“領域”還是領域中的“模型”，終極都是由規則約束出來的具有邊界的問題模型。如果沒有了約束就沒有了Model沒有了Domain，一切可以認識的東西都沒有了，只剩下了一個開放的沒有邊界的宇宙了。可見“規則”（Rule）是多么的重要，而執行規則就需要“驗證”（Validation）。

　　1， 基于構造的驗證

　　將驗證放在構造對象的時候，比如構造函數中或者放在屬性中。在這種情況下，當驗證失敗的時候我們一般直接拋出異常，比如拋出自定義的ValidationException異常，將錯誤信息放在自定義異常中。

public class Person : Entity
    {
        private string _name;
        private DateTime _birthday;

        public string Name
        {
            get
            {
                return _name;
            }
            set
            {
                if (value.IsNullOrEmpty())
                {
                    throw new IsNullOrEmptyException("名稱不能為空");
                }
                _name = value;
            }
        }

        public DateTime Birthday
        {
            get
            {
                return _birthday;
            }
            set
            {
                if (value >= DateTime.Now || DateTime.Now.AddYears(-120) > value)
                {
                    throw new ValidationException("出生日期不在有效的范圍內");
                }
                _birthday = value;
            }
        }
    }        

        

        
        
      
        
it知識庫：總結一下領域模型的驗證（附代碼下載），轉載需保留來源！
        
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。