那么，反观系统架构呢？

我想要的系统架构：能做Winform、Web、WPF、WinCE、Server、大型系统、中型系统、小项目、小工具。

此时计算机会想跟你说2个字：泥煤。 

 

 

与大家一起讨论下系统架构。

独乐乐不如众乐乐，我有我的想法，你有你的想法，思想碰撞在一起才会有火花，否则它就是一个火种，并不绚丽。

 

 

正好最近刚做了一个微信对接的小项目，做的稍微复杂了点，是为了下一个比较大的项目做准备。

 

-> 把跟微信的每个接口对接看作为一条指令（Command）。而触发这条Command执行的是事件（Event），通过处理器（Handler）将Command与Event关联起来。

-> 为了彻底的解耦业务事件层（Business Event）和指令层（Command），我把引用关系给干掉了。那么没有引用关系的话，我又如何让Event触发Command（Handler）呢？

-> 增加一个调度者(中介者)，建立一个关系网，将Event和Command关联起来。

-> 由于微信对接时，除了获取AccessToken等个别特殊接口外，其余都要填充AccessToken，而AccessToken又是有使用时间限制的，超时了要更换，使用次数也有限制，不能每次更换。

     那么问题又来了，能不能别烦躁的次次赋值啊？

     亲爱的，XX大人，在调度者中增加一个预先处理就可以了，为符合特定规则的处理器（Handler）预先调用其他的处理器。

 

 

DataAnnotation：乍一看数据注解好像是没什么关系。其实是用它来关联Event和Handler，间接的通过Event触发Command，而这个配置是在方法上面，以Attribute的方式支持（类似MEF）。
IoC：其实只算是个非常简陋的实例化对象而已，扩展生命周期也成，只是这并不是重点。
惯例优先原则：这个并不是系统架构中明显体现出来的，而是借鉴了伟大的ASP.NET MVC的设计思路，说的明白点儿就是口头约束。

                    不是说强制约束做不了，而是强制约束需要代价，比如编译级错误？运行时错误？为了节约成本，我选择了运行时，而且是很简单的约束。
反射缓存：调度者的实现其实就是反射，而反射是需要消耗性能的，这里我只是简单的优化了一下而已，毕竟这不是重点，只需要把反射关系进行缓存，避免每次都扫描一次就好了。
AOP：这个高大上的词，被我在这里盗用了，在调用Command的前、中、后对各个环节进行拦截，如日志输出，调用顺序监控，数据流转，执行时间等。当然目前还没做到这么复杂，只是简单的完成了调用预先处理器而已。

 

 

 别急，今天只是展开思路，作为一个“序言”。

 接下来的文章会慢慢把这些外衣统统“脱掉”，呦呦呦，外套脱掉脱掉，外套脱掉。

 

PS：这一个系列是以服务端架构为主，不会引用任何第三方的类库、组件等。

 

最后：各位给点个推荐？让我更有动力的写下去，可否？ ^_^