业务逻辑层的设计

你或许也和我一样：

一谈到业务逻辑层，脑海中定会呈现三个字母，那就是“BLL”，我曾经写过的第一个类就非常简单，里面几乎什么也没有，后来就发现它就是个坑，为了填补这个坑，来后一个项目我根本就没有打算要分这层给它了。

直到有一天，辗转反侧睡不着，半夜起来敲代码，我终于领悟了这个BLL的真谛。

我还是用以前的话，“软件设计本身已经够理性了，我们为什么不能用感性一点的文字？”，写者随意，看者轻松。

声明：我会讲一些术语讲的比较白，但可能缺少严谨，但是有些词语不明白可能还是需要搜索一下了。

哪些逻辑应该划分到数据访问层（DAL）

有很长一段时间，我的业务逻辑代码遍布在整个项目代码的任何角落，也同时在操作ADO.NET调用代码的中见缝插针，但我相信这是从一个程序员走向设计师必定要踩过的坑。

之后开始使用O/RM工具，是的，用了它之后我很少使用ADO.NET，因为都被它分装好了，当然也就很少有机会见缝插针了。

在O/RM以及领域驱动设计的思想引领下，我也逐渐在避免存储过程，同时这个习惯也让公司许多业务逻辑从存储过程中移除。

但是O/RM工具在执行事务的时候有两种方式，原理如下：

1、大概是将要增删改的东西全部丢到一个类似于IList<T>的集合之后，当你调用提交事务时，其实是遍历这个IList<T>的集合一次性操作数据库，他又成功地将业务逻辑与操作数据库分离，当你要它回滚的时候，它只需要将集合清空即可。专业点的名词讲，这个叫工作单元（uow）。

2、有时候你会发现，新增了一个实体（或者insert）了以后，你需要马上用到它的ID(标识)继续执行一些相关的操作，这些操作都包含在一个事务中。而且经常在事务中也会穿插那么一点点的逻辑，但通常这些逻辑都比较细粒度，或者说应该将它设计成模块化（讲白点，就是设计时考虑内聚性）。

例如，有个简单的需求是这样的。你需要新增一张订单，订单中包含几个项，所以你在新增订单的同时连同它包含的所有项都保存进数据库。

Order、OrderItem显然是对象模型，存在于BLL。

    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; }
    }

你将会发现，这个类中仅包含操作数据库的逻辑。验证、业务规则都不是它要关注的。在领域驱动设计中，会称Repository为仓储。OrderRepository就是一个特定的仓储，它不需要知道订单中具体有多少个订单项，也不关心它们的名称是否符合规范，这些都应该是BLL的责任，而仓储属于DAL。

    public class OrderRepository
    {
        public void AddOrder(Order order)
        {
            //新增一个Order，并持久化
            foreach (OrderItem item in order.OrderItems)
            {
                //遍历所有项，添加到这个订单。
            }
        }
    }

当我平时在设计的时候，耳边老是有DAL的一个声音，“嘿，这不是我的责任，不要给我做。”

DAL开始踢皮球了。听久了，我逐渐听到了DAL的心声，我开始将许多IF交给BLL来做。

那么BLL应该做些什么？

上面已经提到了验证和业务规则。

让对象模型生动起来，让BLL充实起来，修改Order类

    public class Ordere
    {
        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的验证模块，并且发现IsValid和Vali()都可以在该框架的帮助下完美提取成一个方面（AOP切面编程）。

实际使用当中，也会有一个服务类来服务于客户端的调用，在这里验证，也在这里调用仓储。

小结：由于时间关系，我只能暂时写到这里了，看来写技术博客真的很累，但是写的结果就是对自己和读者都有帮助。

需要注意的是，这篇随笔提到的设计思路，有点偏领域驱动设计的。

其实业务逻辑层也是非常有学问的，这篇随笔也只能点到一个方面，就是哪些逻辑不应该把责任推给数据访问层，也提到了一些处理业务规则和验证的经验。

分类: 架构设计

标签: 架构设计, 领域驱动, 业务逻辑层