基于.net的可扩展框架设计 - 主体思路

近期公司要求设计一个平台，要求所有的程序可以在这个框架内运行，也可以脱离这个框架运行，同时还要有较好的扩展性；第一次看到这个要求感觉这不就是Castle.net的功能嘛。。。但是经过讨论，公司还是决定自己做一个，所以较为简单的模仿了一个Castle框架，并增加了部分自己需要的功能。

该框架主要功能及设计思路:

1）所有的模块都插件化，包括主界面及启动模块Core模块之类的，好处是便于替换，已经通过网络更新。当然坏处是启动速度可能会慢一些。

2）将UI与服务分开，UI尽可能的采用banding，服务则保存在系统的服务容器内。UI与服务之间采用通讯模块进行通讯。 这么做的优点是，我们这个项目是所有的文件都部署在客户端的，但是如果哪天老板想不开了，突然想将服务端部署在服务器上的话，只需要修改这个通讯模块即可。

3）插件与插件之间采用消息模式，插件接口中包含两个方法，一个是获取所有的消息头，一个是获取所有的消息监听器，然后在系统启动的时候，自动将匹配的消息注册；这么做的好处是可以充分解耦合，因为模块之间不知道对方的具体实现，也不会完全依赖于对方，因为只要消息格式确定了，就可以在自己范围内完成自己的任务。

4）权限验证，权限验证本来想选则标准的RBAC模型，但是因为该项目需要兼容老的数据库设计，也只能放弃了；但在设计时，预留了通讯接口的权限验证，保证服务端在执行时会判断是否有足够的权限进行操作。

4）ORM，个人希望采用Entity Framework，但是这个白痴项目除了常见的数据库要兼容外还要兼容各种白痴的中间件，没办法，只好自己实现一个简单的ORM组件了，但是以为内表达式树解析较为负责，因此放弃了对于Linq的支持，这是一点遗憾。

5）自动升级，因为是基于WinForm的应用，因此会涉及到模块的升级，升级设置为两种一种为HTTP下载，这种采用的是较为简单的WebClient类实现的；另外一种是TCP的，本身想采用ESFramework的，但是最终还是因为各种原因放弃了。

6）动态代理，在实现客户端与服务端通信的时候，使用了动态代理，通过动态代理实现UI与服务的分离。

该框架的优点，功能添加方便，模块升级方便，解耦合较好，UI与服务分离，可以快速的完成单机与CS模式的转换，非侵入式框架。缺点，启动时会一次加载所有的所有的服务，注册所有的消息，可能会使用较多的内存，不适合BS模式。

今天先写这么多好了，改天再具体的记录详细的设计。