框架设计总结

前言

毕业7年多时间，GIS出身的我从毕业就开始走上了编程的道路，接触过c++、java、.net,不过最终.net成了我营生的工具。

7年终准确地说待过3家公司，纯作GIS软件的，一家作电信运营商软件的，如今这家作民航业务的，这3家公司有个共同点就是CS为主，偶尔冒出一个两个的BS小项目技术上也就是练练手入个门而已，因此始终对CS的框架比较关注，本身想作个总结，欢迎你们补充和指正。

整体框架

整体框架决定这个系统的将来诸多方面的命运，

例如可扩展性：好的框架会预留必定程度的扩展能力，让未知的需求未来有容身之地；可读性：团队不是一成不变，加上如今的跳槽率一直很高，因此框架可读性是决定之后新人加入后上手、维护的成本，以及他的感觉（谁也不想维护一个像垃圾堆同样的代码）；可维护性：总体结构设计要很容易理解，设计要深刻，不是项目开始的时候一拍脑壳1个小时内决定了怎么设计就按照这种方式去作，若是这样的话你或者你的团队终将付出代价；可复用性：好的设计能剥离出业务相关的东西，业务无关的东西、项目间通用的东西等等，是个技术积累沉淀的过程，也是自我提升的途径。等等诸如此类特性不一一赘述了。

模块管理：系统由各个功能模块组成，每一个模块包括不一样业务功能，将这些模块灵活的管理个人方法是采用反射，设计一个配置文件xml或者db table都行，配置功能模块的Show menugroup、icon、Initialize，系统启动时统一加载，若是将来像换个实现方式也不须要更新全部程序，只须要修改配置文件，替换功能对应的dll便可，或者改下菜单图标、名称等等。

容器：这么多模块来回切换，须要一个容器来装载，根据项目需求能够是single docment也能够是multiple docment，这些统一交给容器来初始化、缓存、切换显示等。容器与模块是松耦合的，若是以为容器设计很差看，能够单独换掉容器部分，其余部分不用变。

组件管理

我这里把模块和组件分开来讲，是根据模块是功能性的，与业务相关的，组件应该是包括模块的，有功能性组件，有非功能性组件，例如一些通用Util类等。

• 我在框架搭建的时候，通常要求具备一个Common目录，里面包含的组件有：

DataAccess：数据访问组件，包含几个经常使用数据库的provider，随着项目的积累能够逐渐补充其余数据库的访问。里面定义了经常使用的GetDataTable，GetDataSet、ExecuteNonQuery、Transcation、ExecuteReader等经常使用操做。

Config：配置组件，一个系统不免有一些配置文件，经过通用的配置组件来读取、访问他们、能够写一个泛型类便可解决，技术简单但思路很清晰很好用，我的以为。

Log：日志组件，不少人用log4net都行，我通常是本身写的，也没多少代码，但用起来顺手。

Util：工具组件，定义一些经常使用的而且通用的xml序列化、反序列化、压缩、读取excel、文件操做、directory操做等等，也是个随着本身经历的项目越多逐渐补充积累的组件。

Control：控件组件，通常项目都有固定的界面组件库，能够基于公司经常使用的库，根据业务特性作一些展现上的封装，通常的功能能够就直接拿来用了，界面统1、速度快、省事省力，例如咱们之前表格、趋势图、柱状图、仪表盘展现不少，封成组件后只须要给一个DataSource就能够了。

DataType：数据类型，为通用组件服务的一些数据结构和类型。

• 除了通用的组件外，还有就是业务方面的，通常我建一个Modules目录，里面包括：

模块里的通用部分，我叫它InternalCommon，包括：

Entity：模块数据结构

DataMapper：模块的一些数据访问封装，有些查询类的能够不封装，管理编辑系统的数据访问方式有限能够作封装。

模块中部分模块共用的一些InternalUtil、InternalControl、InternalService等等

模块自己部分：直接叫Modules，根据业务需求分红不一样的模块，划分的依据通常根据业务相关性，相关性大的放在一个模块里，便于管理和阅读、未来修改某个功能只须要替换某个功能模块dll便可。

组件通讯

通讯通常咱们会想到事件event，这种两个组件或者窗体间的通讯是紧耦合的，通常模块内部会使用，但模块与模块之间的通讯通常采用事件聚合器来作，

事件聚合器的有点是松耦合的，全部的消息管理都有聚合器自己去作，你只须要在发消息的模块中Publish消息，在收消息的地方Subscribe消息，给一个约定好的ID以及封装数据的结构便可。但也要慎用，用得太多到时候跟踪调试的时候比较麻烦，因此个人原则是模块级别的消息用它来作，普通的消息仍是用.net的event来完成。

数据访问

见组件管理里对应部分

配置管理

见组件管理里对应部分

日志管理

见组件管理里对应部分

角色权限

这也是一个系统不可或缺的部分，比较重用的作法是创建角色与用户：

角色拥有权限，而后设置角色与用户的对应管理，每一个用户对应有一个或多个角色，每一个角色可分配给多个用户，一种m:n的关系

有些系统会涉及到按钮级别的权限，我的以为这种不是太多，若是有的话能够在角色下设置功能节点，功能节点下设置按钮节点，对其进行权限设计。

多语言化

当时我作的有些项目会买到海外，因此涉及到了一些多语言的东西，不过当时设计方案很通常，有没有可借鉴的价值请本身衡量 呵呵。

最外层有一个多语言的配置，用于系统最经常使用的OK 、Cancle、Commit、Update等等，由于一个系统这类型的按钮基本上会这么叫，因此不必重复定义。

但也有一些不这么叫的那就用功能自身的多语言配置文件，每一个功能模块对应一个本身的配置，若是想覆盖最外层的配置，直接新增一个便可。

还有一些状况，好比表格内的字段名称，图的xy轴显示等可单独提出来一个节点，方便维护，也避免表内、图内的文字与表外图外的冲突。

系统缓存

固然系统缓存也少不了，不过实现起来也很简单。定义一些全局对象，用于存放系统级的数据和配置，须要时不用再请求数据库等。

写出来是以为本身能力有限，目前只总结到这个层次，欢迎各位拍砖。