業務邏輯層的設計（一）——邏輯是誰的職責

 

如何讓一些業務邏輯重用

有很長一段時間，我的業務邏輯代碼遍布在整個項目代碼的任何角落，也同時在操作ADO.NET調用代碼的中見縫插針，但我相信這是從一個程序員走向設計師必定要踩過的坑。

 

有個簡單的需求是這樣的。你需要新增一張訂單，訂單中包含幾個項，所以你在新增訂單的同時連同它包含的所有項都保存進數據庫。

Order、OrderItem顯然是領域模型，而且它們之間是一對多關系。

    public class Order
    {
        private IList<OrderItem> _orderItems = new List<OrderItem>();

        public virtual IList<OrderItem> OrderItems
        {
            get { return _orderItems; }
            set { _orderItems = value; }
        }

        public virtual string Name { get; set; }
    }

    public class OrderItem
    {
        public virtual string ItemName { get; set; }
    }

 

規則驗證

加入了訂單名稱的長度限制。

    public class Order
    {
        private string _name;
        private IList<OrderItem> _orderItems = new List<OrderItem>();

        public virtual IList<OrderItem> OrderItems
        {
            get { return _orderItems; }
            set { _orderItems = value; }
        }

        public virtual string Name
        {
            get { return _name; }
            set
            {
                if (value.Length <= 0 && value.Length > 25)
                {
                    throw new IndexOutOfRangeException("訂單名稱必須在0-25個字符以內");
                }
                _name = value;
            }
        }

        public bool IsValid
        {
            get
            {
                if (Name.Length <= 0 || Name.Length > 25)
                {
                    return false;
                }
                return true;
            }
        }

        public string Vali()
        {
            StringBuilder builder = new StringBuilder();
            if (!this.IsValid)
            {
                if (Name.Length <= 0 || Name.Length > 25)
                {
                    builder.AppendLine("訂單名稱必須在0-25個字符以內");
                }
            }
            return builder.ToString();
        }
    }

下面來模擬一下實際調用驗證

        [Test]
        public void TestVali()
        {
            Ordere order = new Ordere();
            order.Name = "";
            if (!order.IsValid)
            {
                //Name長度為0顯然不合法，這里果斷沒有通過驗證。
                Console.WriteLine(order.Vali());
                //Vali方法讓我們知道了驗證沒有通過的原因
                //訂單名稱必須在0-25個字符以內
                //Expected: True
                //But was:  False
            }
            Assert.AreEqual(false, order.IsValid);
        }

實際使用當中，其實完全可以引入微軟企業庫5.0的驗證模塊，利用特性來取代手動編寫Vali方法的內容。

 

填充業務邏輯

 例子中的業務比較簡單，

實踐中，我經常遇到一種流程控制的業務邏輯，

比如：

我在流程1要提交，必須要當前進度處於流程狀態1，

我在流程1要撤銷提交，必須要當前進度處於流程狀態2（已提交）

這個業務整在領域模型里面，可以避免散落各處，

當我需求修改為：

流程1要提交，必須要當前進度處於流程狀態1或7，只需要修改一處即可，減少了各處修改出錯的可能。