【轮子狂魔】轮子的魅力之扩展能力

序言

如果你是第一次看本文，建议先看下前面两篇，否则你可能会一头雾水

• 【轮子狂魔】序言：有没有那么一种系统架构，它是无所不能的
• 【轮子狂魔】打造简易无配置的IoC

看过上一篇【轮子狂魔】打造简易无配置的IoC的人，可能会有几个疑问，我统一回答一下吧。

1.你这说是IoC，但感觉不像啊。

   首先，我在百度百科里把IoC的概念Copy过来看看。

   控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题，也是轻量级的Spring框架的核心。 控制反转一般分为两种类型，依赖注入（Dependency Injection，简称DI）和依赖查找（Dependency Lookup）。

    那么，IoC一定是AutoFac、Unity之类的吗？它什么时候被标签上一定要与这些第三方功能一致的标签？

    在我上篇文中，我使用的是参数注入，缓存反射关系的依赖查找方式。所以我说是简易的IoC应该没什么问题。

2.有人在上一篇看到了CQRS或者DDD的影子。

    实话说我最近确实看过这方面的东西，受到了一些启发，所以命名上有点贴近这方面技术名词，但这仅仅是名字相近而已。

3.为什么要出这样一个系列？

    我希望我可以从因果关系上解释出遇到什么样的问题，可以有什么样的方法应对，或者以什么样的顺序来搭建我们的系统架构，这并不是一个标准，而是个人的经验，仅供参考而已。

    另外我也希望大家可以扩展思维，发现架构是可以“造”出来的，而不是“拷贝”出来的，不要落入三层、MVC、MVVM、SOA等里面。

 

改造，让架构更智能

开发微信时发现一个可以提炼出来的共同点：交互接口参数中需携带AccessToken

而这个AccessToken有多么烦人，在上一篇已经提过我就不再赘述了。

 

IAccessTokenAuth的由来

我们要做的是让架构可以帮助我们自动填充这个AccessToken，那我们就先给他定义为一个接口，方便后面去针对接口操作，

同时，Event是穿梭在Event、Dispatch、Command三个层中，所以最适合的地方就是在事件里，而接口也是由各个事件自己去实现。

 

    /// <summary>
    /// 微信接口交互凭据授权接口
    /// </summary>
    public interface IAccessTokenAuth
    {
        string AccessToken { get; set; }
    }

 

DispatchBeforeActiveHandler的由来

我们要想清楚这个接口需要在什么时候执行？

就以当前的业务来说，肯定是在执行微信指令之前填充。

所以执行顺序当然是在普通的调度处理器执行前，为了统一执行方式，我们也需要把这个看作是一个调度处理器，只是执行顺序特殊一些。

因为调度器建立关系网是根据特性(Attribute)来的，我们就让这个特殊的调度器继承自DispatchHandlerAttribute的类。

  

1     [AttributeUsage(AttributeTargets.Method)]
2     public class DispatchBeforeActiveHandlerAttribute : DispatchHandlerAttribute
3     {
4         public DispatchBeforeActiveHandlerAttribute()
5             : base(typeof(DispatchHandlerAttribute))
6         {
7 
8         }
9     }

 

如何使用IAccessTokenAuth？

以创建菜单为例

    /// <summary>
    /// 创建菜单事件
    /// </summary>
    public class CreateMenuEvent : DispatchEvent, IAccessTokenAuth
    {
        public string AccessToken { get; set; }

        public MenuList MenuList { get; set; }
    }

 

如何使用DispatchBeforeActiveHandler？

 根据业务分类，我们把FillAccessToken方法加到AccessTokenCommand类中

 1     /// <summary>
 2     /// 微信交互接口凭证命令
 3     /// </summary>
 4     public class AccessTokenCommand
 5     {
 6         #region 静态构造函数
 7 
 8         static AccessTokenCommand()
 9         {
10             AutoUpdateCache.Add(CacheKeySet.AccessToken.ToString(), new AutoUpdateItem()
11             {
12                 UpdateValue = (AutoUpdateItem autoUpdateItem) =>
13                 {
14                     var accessTokenInfo = CommandHelper.GetWeChatResponseObject<AccessTokenInfo>(new AccessTokenCommandRequest());
15 
16                     autoUpdateItem.ExpiredSeconds = accessTokenInfo.ExpiresIn - 30;//预留过期时效，防止提前过期
17                     autoUpdateItem.Value = accessTokenInfo;
18                 }
19             });
20         }
21 
22         /// <summary>
23         /// 填充微信接口交互凭据
24         /// </summary>
25         /// <param name="e"></param>
26         [DispatchBeforeActiveHandler()]
27         public void FillAccessToken(DispatchEvent e)
28         {
29             IAccessTokenAuth accessTokenAuth = e as IAccessTokenAuth;
30             if (accessTokenAuth == null)
31             {
32                 return;
33             }
34 
35             var getAccessTokenEvent = new GetAccessTokenEvent();
36             Dispatcher.ActiveEvent(getAccessTokenEvent);
37 
38             accessTokenAuth.AccessToken = getAccessTokenEvent.AccessTokenInfo.AccessToken;
39         }
40 
41         #endregion
42 
43         /// <summary>
44         /// 获取微信交互接口凭证
45         /// </summary>
46         /// <param name="e"></param>
47         [DispatchHandler(typeof(GetAccessTokenEvent))]
48         public void GetAccessToken(GetAccessTokenEvent e)
49         {
50             e.AccessTokenInfo = AutoUpdateCache.GetValue<AccessTokenInfo>(CacheKeySet.AccessToken.ToString());
51         }
52     }

我们看到FillAccessToken有一个参数DispatchEvent，一个原因是我们需要为这个事件内的AccessToken赋值，还有一个原因是它是一个基类，这样我们就可以处理任何的事件。

另外FillAccessToken判断DispatchEvent是不是IAccessTokenAuth接口，来判断是否需要填充AccessToken。

为什么是做在这里而不是在调度器？因为调度器尽量保持中立，不要接触过于细节的业务逻辑，所以放在这里来校验是否需要填充AccessToken更合适。

 

如何让调度器支持DispatchBeforeActiveHandler？

 1.添加一个激活前处理器列表

 2.建立关系网时，分开处理DispatchBeforeActiveHandler和DispatchHandler

 3.在ActiveEvent方法中，执行DispatchHandler之前，先循环遍历DispatchBeforeActiveHandler

    /// <summary>
    /// 调度器
    /// </summary>
    public class Dispatcher
    {
        /// <summary>
        /// 调度关系网
        /// </summary>
        private static Dictionary<Type, List<DispatchHandlerAttribute>> _dicDispatchRelativeNetwork = new Dictionary<Type, List<DispatchHandlerAttribute>>();

        /// <summary>
        /// 激活前处理器列表
        /// </summary>
        private static List<DispatchHandlerAttribute> _lstBeforeActiveHandler = new List<DispatchHandlerAttribute>();

        /// <summary>
        /// 建立调度关系网
        /// </summary>
        /// <param name="assembly"></param>
        public static void BuildDispatchRelationship(Assembly assembly)
        {
            Logger.Info("调度器：开始建立调度关系网...");

            var types = assembly.GetTypes();

            foreach (var type in types)
            {
                var methods = type.GetMethods();

                foreach (var method in methods)
                {
                    var attribute = method.GetCustomAttributes(typeof(DispatchHandlerAttribute), true).FirstOrDefault();
                    if (attribute != null)
                    {
                        CheckParameterRule(method);

                        var handler = attribute as DispatchHandlerAttribute;
                        handler.DispatchInstance = Activator.CreateInstance(type);
                        handler.ActionMethodInfo = method;

                        if (attribute is DispatchBeforeActiveHandlerAttribute)
                        {
                            AddBeforeActiveHandler(handler);
                        }
                        else
                        {
                            AddDispatchRelation(handler);
                        }
                    }
                }
            }
        }

        /// <summary>
        /// 添加激活前处理器
        /// </summary>
        /// <param name="handler">调度处理器</param>
        private static void AddBeforeActiveHandler(DispatchHandlerAttribute handler)
        {
            _lstBeforeActiveHandler.Add(handler);

            Logger.Info(string.Format("调度器：增加激活前处理器 [{0}]-[{1}.{2}]", handler.ObservedDispatchEventType.Name, handler.DispatchInstance.GetType().Name, handler.ActionMethodInfo.Name));
        }

        /// <summary>
        /// 添加调度关系
        /// </summary>
        /// <param name="handler">调度处理器</param>
        private static void AddDispatchRelation(DispatchHandlerAttribute handler)
        {
            var eventType = handler.ObservedDispatchEventType;

            if (!_dicDispatchRelativeNetwork.ContainsKey(eventType))
            {
                _dicDispatchRelativeNetwork.Add(eventType, new List<DispatchHandlerAttribute>());
            }

            _dicDispatchRelativeNetwork[eventType].Add(handler);

            Logger.Info(string.Format("调度器：建立新的关系网 [{0}]-[{1}.{2}]", eventType.Name, handler.DispatchInstance.GetType().Name, handler.ActionMethodInfo.Name));
        }

        /// <summary>
        /// 检查参数规则
        /// </summary>
        /// <param name="method"></param>
        private static void CheckParameterRule(MethodInfo method)
        {
            var parameters = method.GetParameters();
            if (parameters == null ||
                parameters.Length != 1 ||
                (!parameters.FirstOrDefault().ParameterType.Equals(typeof(DispatchEvent)) &&
                 !parameters.FirstOrDefault().ParameterType.BaseType.Equals(typeof(DispatchEvent))
                ))
            {
                throw new Exception(string.Format("DispatchHandler - [{0}]的参数必须是只有一个且继承自DispatchEvent", method.Name));
            }
        }

        /// <summary>
        /// 激活事件
        /// </summary>
        /// <param name="dispatchEvent">调度事件</param>
        public static void ActiveEvent(DispatchEvent dispatchEvent)
        {
            var type = dispatchEvent.GetType();

            if (!_dicDispatchRelativeNetwork.ContainsKey(type))
            {
                Logger.Error(string.Format("调度器：当前事件[{0}]没有找到绑定的Handler", type.FullName));
                return;
            }

            _lstBeforeActiveHandler.ForEach(action =>
            {
                ActiveAction(action, dispatchEvent);
            });

            _dicDispatchRelativeNetwork[type].ForEach(action =>
            {
                ActiveAction(action, dispatchEvent);
            });
        }

        private static void ActiveAction(DispatchHandlerAttribute action, DispatchEvent dispatchEvent)
        {
            try
            {
                action.ActionMethodInfo.Invoke(action.DispatchInstance, new object[] { dispatchEvent });
            }
            catch (Exception ex)
            {
                if (ex.InnerException != null && ex.InnerException.GetType().Equals(typeof(WCFLib.ExceptionExtension.GException)))
                {
                    throw ex.InnerException;
                }
                else
                {
                    throw;
                }
            }
        }
    }

 

激活Event的代码变成什么样子？

 

1             var getAccessTokenEvent = new GetAccessTokenEvent();
2             Dispatcher.ActiveEvent(getAccessTokenEvent);
3             var accessTokenInfo = getAccessTokenEvent.AccessTokenInfo; 

是的，你没看错，没有变化！

同时，在真正的创建菜单事件中也不需要处理任何有关AccessToken的业务逻辑。

因为创建菜单的指令也很简单，我就不贴代码了，跟GetAccessToken差不多，只是处理微信指令时逻辑上不太一样而已。

 

为什么我喜欢造轮子？

 在满足技术条件的基础上，轮子的可控性更高，可扩展性也更高。

 轮子的发展方向会根据我们的业务进行调整，同时去掉了我们并不需要的一些附带功能。

 绝大多数第三方是做一个通用的类库，而我造的轮子不是，我造的是更贴近系统业务的，更贴近团队技术水平的。

 不论是从封装也好，调用也好，各个角度来看，我们都能够控制轮子的形态，让轮子成为我们非常熟悉的调用方式。学习成本会也自然就会降低。

 轮子有好有坏，看你从哪个方面来看，这个不需要去争论，我们只需要保持着可用性、可扩展性、性能达标的标准去走即可。

 最后，我并不鼓励盲目的造轮子，这是我从始至终的观点，但我仍然坚持造最适合自己的轮子，两者并不冲突。 ^_^