[CAMCOCO][C#]我的系統架構.服務器端.（四）----Model層 實體的自我驗證

這是Model的第二篇，上一篇點這里

 

這塊完全是扒了@何鎮汐大神博客里的教程實現的，在這之前完全沒想到數據驗證居然可以這樣做！！在此表示嚴重感謝！！！

點擊這里可以去了解這個方法的原理，老胡估計自己是完全說不清楚的了。http://www.cnblogs.com/xiadao521/p/4111815.html

還是來圖上看

Validation部分，這里是從@何鎮汐教程中拔過來的代碼，

老胡只是在_BaseEntityValidation類里面進行了簡單的集成進來。

namespace CAMCOCO.Model.Core.Entity
{
    using System.Collections.Generic;
    using Validation;

    public partial class _BaseEntityValidation
    {
        private readonly List<IValidationRule> _validationRules;
        private ValidationHandler _validationHandler;

        protected _BaseEntityValidation()
        {
            _validationRules = new List<IValidationRule>();
            _validationHandler = new ValidationHandler();
        }

        public override void Dispose()
        {
            base.Dispose();
            _validationRules.Clear();
        }

        /// <summary>
        /// 為實體對象添加一條驗證規則
        /// </summary>
        /// <param name="rule">驗證規則</param>
        public void addValidationRule(IValidationRule rule)
        {
            if (rule != null)
            {
                _validationRules.Add(rule);
            }
        }

        /// <summary>
        /// 對實體對象進行合法性驗證，如果驗證失敗，將通過throw Exception進行拋出
        /// </summary>
        public void validate()
        {
            IValidationResultCollection results = getValidationResult();
            _validationHandler.handle(results);
        }

        private IValidationResultCollection getValidationResult()
        {
            IValidationResultCollection result = ValidationFactory.createValidationor().validate(this);
            foreach (var rule in _validationRules)
                result.addResult(rule.validate());
            return result;
        }



    }
}

有了這個神器，在業務邏輯層里實現數據驗證簡直就是一種享受。

下面是在業務層調用的時候的代碼樣子：

public void addPopedomGroup(PopedomGroup obj)
        {
            try
            {
                IRepository<PopedomGroup> res = createRepository<PopedomGroup>();

                PopedomGroup dbObj = PopedomGroupFactory.createPopedomGroup();
                dbObj.cloneFromWithProperties(obj, "Name", "IsHidden");
                dbObj.Order.Index = createNewOrderIndex<PopedomGroup>();

                dbObj.addValidationRule(new PopedomGroupCannotExistsSameNameRule(res, dbObj));
                dbObj.validate();
                res.add(dbObj);
                commit();
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

dbObj.addValidationRule(new PopedomGroupCannotExistsSameNameRule(res, dbObj));

這句代碼可以很方便地在本次邏輯操作中加入任何的驗證條件，而驗證規則的編寫也很簡單，同時可以實現任意組合。

例如：

namespace CAMCOCO.Business.Authentication.Rule
{
    using System.ComponentModel.DataAnnotations;
    using CAMCOCO.Business.Core.Rule;
    using CAMCOCO.Model.Core.Validation;
    using CAMCOCO.Data;
    using CAMCOCO.Model.Authentication.Entity;

    public class PopedomGroupCannotExistsSameNameRule : BaseRule<PopedomGroup>
    {
        public PopedomGroupCannotExistsSameNameRule(IRepository<PopedomGroup> res, PopedomGroup checkObj)
            : base(res, checkObj)
        {

        }

        public override ValidationResult validate()
        {
            ValidationResult result = ValidationResult.Success;
            if (_res.exists(m => m.Id != _checkObj.Id && m.System.DeleteFlag == false && m.Name == _checkObj.Name))
            {
                result = createValidationResult("PopedomGroup", "權限組名稱不能重復");
            }
            return result;
        }
    }
}

 

 

OK，到此為止，老胡的實體模型基類基本就搭建完畢了，在老胡的架構里，所有的實體類都必須從三大基類（BaseEntityNormal, BaseEntityOrder, BaseEntityTree）派生而來，具備如下一些特性：

1、所有的實體都有唯一的一個ID號。

其實這個問題展開來還有一系列的考慮，在之前的項目經驗中，我采用過兩種形式的ID，一種是數據庫自增標識，一種是Guid。兩種方式分別都有自己的優點，自增標識屬於數據庫自主管理，我們寫代碼的時候不同進行維護，同時所有ID號都是連續的，優點是方便記憶，能夠快速定位數據，夠直觀。同時缺點也是明顯的，由於自增特性，我們沒法手工任意修改，當需要做數據遷移或者在系統之間導入導出數據時，這個東西很麻煩，你得先建立一個臨時表用於記錄新老ID對應記錄等等，同時因為其是連續的數字，如果在安全驗證上出現漏洞，很容易就被用戶調取到不屬於自身范圍的數據。而GUID正好解決以上兩個問題，同時GUID帶來的問題就是無法記憶無法推算，在開發及測試程序時無法很好地預判結果和肉眼查找數據。

在老胡做這個架構的時候，兩種方案都嘗試了，最終為了保留EF中的某些重要特性，比如GUID模式通過EF無法自動生成符合老胡要求的主鍵，我希望數據的保存依托ID作為主鍵同時是一個聚集索引，但GUID明顯不適合做聚集索引。手工制表的時候老胡一般都是吧GUID作為主鍵，然后去掉聚集索引，將聚集索引建立在數據創建時間字段上。

2、所有實體都會記錄下創建時間；

3、所有實體都是邏輯刪除；

4、Order類實體可以通過框架標准接口進行排序；

5、Tree類實體可以通過框架標准接口進行排序操作和節點操作；

6、所有實體都具備完整的自我合法性驗證功能；

7、實體模型可以被業務層及以上的任意層使用，但以為除了業務層意外均不掌握修改實體的方法，所以實體數據的安全性得到了保障，要修改實體內容，只能通過業務層；

8、通過EntityBuilder建造者來初始化實體基類信息，派生類中不用關心其基類部分的屬性該如何賦值；

 

BaseFilter的特性：

1、凡是有查詢需求的實體，都因為為其構造Filter，而這些Filter都必須派生自BaseFilter；

2、BaseFilter中已經將實體基類中的標准屬性進行了定義，派生類中只需要針對派生實體的特定屬性進行特定擴展即可；

3、Filter本身不應該有任何操作功能，只是一堆屬性定義（和貧血實體一樣）；

4、Filter的目的是取代查詢函數里的一大堆參數而存在的

//普通查詢接口
IQueryable<Entity> findEntityList(long id, string searchName, int maxThanAge, ...);

//采用Filter模式
class EntityFilter{
    public int Id{get;set;}
    public string searchName{get;set;}
    public int maxThanAge{get;set;}
    //...
}

IQueryable<Entity> findEntityList(EntityFilter filter);

 

 

這是Model的第二篇，上一篇點這里