三年多前还在上研时，用C#+反射机制写过插件系统，后来又用MEF写过插件系统。插件系统本身具有易于扩展的优势，所以在实际项目中使用很频繁。即使在B/S项目中，插件的思想也是大行其道，比如前端单页面+AMD编程便可以理解为一种插件机制，以及后台扩展项目统一打包为一个jar放入主系统jar文件中一起发布，也可以理解为插件思想的运用。
这里我们回到C/S插件系统编写的问题上。由于之前诸多项目编写是将插件编译成dll，然后进行解析。这样做有其好处，即宿主中可以对各个模块解析，完成插件间、插件和主程序间的通信。但是在实际项目中，同样也有其劣势：
a.每一个插件被编译成了dll，各模块无法单独运行，必须依托于主程序。
b.修改插件时，由于生成的是dll，无法快速直观的查看修改以及调试。
c.每一个插件必须依赖于某一个规范。
当我们并不需要插件之间、插件和主程序之间有通信发生时，我们是否可以舍弃这种dll插件形式呢？
此项目背景，即各模块之间无需通信。并且为了适应各模块能独立运行以及各模块需要单独调试的需求，这里我直接将各模块设计为单独的系统，即编译后生成exe。在主系统中，通过对配置文件的解译，生成界面以及绑定相关回调事件。各插件exe以配置规则放入主程序文件夹下即可。
a.C#调用exe，使用PRocess和 ProcessStartInfo配合完成。
b.完成各模块(exe)的单例模式。
由于是直接调用exe，无法利用传统的单例模式实现。这里可以做一个字典表来存储，目前哪些模块已经被调用。
但是，当循环监听模块是否退出时，会导致系统卡顿，这里使用多线程来进行模块开启，解决监听模块导致的界面卡顿。
c.主程序退出时，所有模块(exe)退出。
用字典表存储各模块的实际进程，主程序退出时，将各进程杀死关闭。
宿主界面：
点击服务发布模块：
——欢迎转载，但保留版权，请于明显处标明出处：http://www.VEVb.com/naaoveGIS/
新闻热点
疑难解答
