MAF应用框架设计总结I——缘起

        MAF框架脱胎于去年开发的一个WinForm项目。这个项目中，实现了一个简单的类VisualStudio的多Tab页风格的主用户界面。所有的功能模块以UserControl的形式开发，并作为插件集成进主用户界面。这个框架采用了反射（+配置文件）+类厂的方式把控件动态加载并显示在界面上，并集成进了权限控制机制，使项目开发人员摆脱了以往界面集成和权限验证的一些重复繁琐的编码工作，显著提高了开发效率。
        不过，由于本人设计经验不足，这个框架采用了白盒复用的方式来实现——将用户控件直接作为插件处理，设计统一的父控件/插件类，其中包括权限控制、编辑状态、数据访问等多方面的控制逻辑，导致以下一些问题：
        1、可用性差。除了重载一些虚方法之外，开发人员还需要理解和使用很多基类定义的标志、工具方法的意义和使用。很多bug都是由于忘记了调用某个方法或者设置某个标志而造成的。
        2、框架侵入性太强。由于太多的基础设施是由父类提供，造成子类控件对框架的高度依赖。这样的控件无法在框架之外进行开发和测试。随着项目的规模逐渐膨胀，编译->执行->跟踪变得越来越慢，而自动化单元测试则更成为了一种奢望。
        3、扩展性和可维护性不佳。由于在同一个类（作为插件的控件）里面做了太多的事情，在开发时经常是顾此失彼，因此而产生了很多bug。由于插件类的粒度过大，也造成了设计方案一致性的失控，产生了一些自相矛盾的设计，由于这些细节被子雷高度依赖，因此修改起来格外困难。而当时项目开发时间比较紧张，使框架的开发只能和应用并行进行，成倍地放大了问题带来的影响。
        4、设计方案不完善。由于控件即插件，因此对权限的划分粒度很单一，灵活性差，经常需要在代码里面打一些“补丁”来满足一些看上去很刁钻实际又很常见的权限验证需求。
        今年初，我参与了一个新的项目：把公司一些比较老的使用vb开发的系列产品，移植到.net平台上面来。根据这些产品的运维要求，头儿要求为这些产品提供一个统一的平台，特别是需要实现一个插件式的体系结构，以利于产品的部署、维护和升级。这个项目的时间是3个月。
        相似的问题又摆在我面前了。不同的是，经过去年那个项目“趟雷”式的开发，心里多少有了点底，至少，不会踩到比去年还多的雷吧~~
        要解决的问题总结如下：
        1、支持以插件的方式实现功能扩展
        2、支持在线缺陷报告和自动升级
        3、需要框架和应用并行开发

（土鳖扛铁牛...）

注：MAF是个马赛克处理过的名字，真实名称已不可考