关键字: 迭代器模式, 关注点分离

返回引言目录

最近工作中,要处理一个生成查询条件问题,代码写的很乱. 认真思考后觉得可以重构一下,让它更加面向对象.
如果大家有更好的建议，欢迎提出讨论。如果有类似问题也可以在评论去提出。谢谢

需求####

需求: 用户通过QueryBuilder,构建出筛选条件, 筛选可能使用几张表内字段, 根据筛选所使用的字段生成几张表的Join关系. 如果某个筛选条件是选项查询，则需要查出该字段所有的选项值。

需求不复杂,只需要找出用的所有字段,查出对应的表名,根据规则构建出SQL的Join条件就好。 以及根据查询条件确定选项字段，查出对应的选项值即可。 问题是QueryBuilder生成的对象是一个树状结构,需要遍历整颗树来找出所有字段. 这个也不复杂.

代码初稿#####

public static void GetAllDistinctFieldID(List<QueryBuilderRuleViewModel> rules, List<string> fieldIDs, bool isOption)
{
    if(rules != null)
    {
        foreach (var item in rules)
        {
            if (item.rules == null)
            {
                if(string.IsNullOrWhiteSpace(item.field)== false && fieldIDs.Contains(item.field) == false)
                                {
                                       if(isOption)
                                       ｛
                                              if(item.input == "select”） fieldIDs.Add(item.field);
                                        ｝else
                                        {
                                            fieldIDs.Add(item.field);
                                        }
                                  }
            }
            else
            {
                GetAllDistinctFieldID(item.rules, fieldIDs, isOption);
            }
        }
    }
}

上面代码很简单,好像也没有什么问题, 递归查找整个树,找出叶子节点, 根据条件把叶子节点的字段名取出来,去重加入到字段列表就好.
实际代码比这个复杂点,这是整理过后的版本
这个版本有什么问题了,太过面向过程了,不够面向对象.:-)

• 混合两种处理取字段逻辑，相互干扰
• 混合遍历字段的技术需求和取字段的业务需求
• 代码阅读起来很累，需要同时考虑两种逻辑(遍历和选择业务)
• 当业务需求变更时，维护困难

简单思考后，决定采用下面的设计思路来改造上面的代码

OO原则:####

关注点分离（Separation of concerns，SOC）是对只与“特定概念、目标”（关注点）相关联的软件组成部分进行“标识、封装和操纵”的能力，即标识、封装和操纵关注点的能力。是处理复杂性的一个原则。由于关注点混杂在一起会导致复杂性大大增加，所以能够把不同的关注点分离开来，分别处理就是处理复杂性的一个原则，一种方法。

设计模式:####

迭代器模式是一种设计模式，是一种最简单也最常见的设计模式。它可以让用户通过特定的接口巡访容器中的每一个元素而不用了解底层的实现。

改造后的代码:
迭代器，只用来遍历所有规则，采用了堆栈来避免递归。但是这个不是重点，用递归也一样可以实现迭代器。

public static IEnumerable<QueryBuilderRuleViewModel> FlatRule(this List<QueryBuilderRuleViewModel> qbrs)
{
     if (qbrs != null){
         Stack<QueryBuilderRuleViewModel> ruleStack = new Stack<QueryBuilderRuleViewModel>();
         qbrs.ForEach(p => ruleStack.Push(p));                
         while (ruleStack.Count > 0)
         {
            var ruleItem = ruleStack.Pop();
              if (ruleItem.rules == null)
                  yield return ruleItem;
             else
                 ruleItem.rules.ForEach(p => ruleStack.Push(p));
          }
    }
}

查出所有使用的字段

queryFieldIDs = qbr.rules.FlatRule()
                    .Select(p => p.id)//选出字段ID
                    .Where(p => string.IsNullOrWhiteSpace(p) == false)//排除空ID,无效ID
                    .Distinct()//去重
                    .ToList();

查出所有需要检索选项值的字段。

queryFieldIDs = qbr.rules.FlatRule()
                    .Where(p=>p.Input == "select")//选出选项查询条件
                    .Select(p => p.id)//选出字段ID
                    .Where(p => string.IsNullOrWhiteSpace(p) == false)//排除空ID,无效ID
                    .Distinct()//去重
                    .ToList();

点评######

改造后的代码，看起来还比以前多一点。但是代码逻辑已经分开，不同的部分处理不同的逻辑，每处的关注点都不同。
在迭代器主要是技术细节，如何遍历整课树。这个逻辑可以一直使用，只和QueryBuilder的存储结构相关。
而后面两段逻辑，则是业务逻辑，代码具有极强的可读性，和需求提供的业务规则基本是用同一种语言描述的。当业务规则变化，就可以很快的修改这段逻辑。调试，维护时，也可以很明白的看出这段逻辑有没有问题。
这就是关注点分离原则的作用。
迭代器模式是一个简单模式，但是简单的模式用的好一样都可以起大作用。