NET插件系统之一，开头：MEF的一些疑问和相关思考

      实现可扩展的软件系统是我一直的目标和想法。可扩展性显然属于动态编程的范畴。因此，几个月来我在业余时间会抽空学习插件系统。  

我参考了博客园的几篇插件式系统的文章。知道了实现插件系统有以下的核心流程：

      1. 定义插件接口，并在各个功能组件中实现这些接口

　　2. 在主程序中，通过遍历所需目录下的dll文件，查询实现该接口的type,从而通过createinstance方法实现其动态创建，并加入到主程序插件列表。下面的代码展示了该功能。

    这个流程其实很简单，我也比较方便的实现了自制的插件系统。 但问题随之而来：

      1. 如果该系统是一棵插件树，那么显然我需要不止一次查询所有dll文件，并查询所有type，这会带来显著的性能问题。

      2. 如果某类型不需要在启动时就实例化，那么我可以存储该类型，在需要的时候实现调用。

 　  3. 最核心也是最大的问题： 插件之间的相互访问如何解决，当前我只能采用 从插件列表中找到该引用，然后将其强制类型转换到所需的插件样式。但显然，这种做法很不好，不符合插件隔离，而且必须添加该项目引用。

      4. 我希望能在不实例化该类的前提下获得对象的某些属性， 比如， 一个游戏列表，它会提供这些游戏的名称，图片和相关信息。但这些数据才能如何获得？虽然有attribute，但它所提供的功能显然有限。

      1. mef可以方便的实现插件组件，不需要手动硬编码，但其中的控制权限显然不在用户，有些选项虽然开放，但你很难控制。虽然我知道有lazy泛型，但如哪些方法在什么时候实例化还是很难保证。我并不需要在任何时候都保留所有插件的实例对象，而希望在需要的时候实例化或销毁它，可惜mef未能提供。 

      2. 使用mef后，必须强制将实现插件的各个组件版本升到.net 4.0， 虽然不是太难的事情，但却需要客户端更多的部署。

　　3. mef依旧没有解决插件间通信的问题，它仅仅为你提供了插件的集合，但组件间的事件，通信方法却只字未提。 如果是这样的话，它的功能岂不是太简单？

      4.mef是否有性能问题？它的实现机制显然是反射和attribute, 但搜索目录和某一程序集并实例化的性能如何呢？我没有做过详细对比....

       结合前面，使用import和export关键字实现的mef插件虽然很high,但带来的问题也绝对不少。   但实际上，我们手动实现一个比mef更灵活的系统也不是一件太难的事情，而增加的代码量实际并不多，也不用加入这个依赖库。 于是，mef的价值又有多大呢？

       我非常崇拜vs或者eclipse这样大型软件所实现的插件系统，主核心完全无法知道将来会有什么功能加入，但其可扩展性，性能，结构清晰程度都是像我这样的菜鸟无法企及的。是不是有更复杂的机制，如 事件管道来实现这些功能呢？我不知道。

       当然有很多类型的插件系统，比如maf,我未曾做深入研究，是因为实在学习成本高昂，时间有限，但实际上特别希望能学习这些插件系统的精髓之处。

       非常希望有大牛能解决我的以下问题。

       1.  各插件之间能够解除引用依赖的事件通知方法。 调用难道我要把所有的功能都写入接口么？这显然不现实。

       2. 如何提升插件搜索组件的速度和性能？

       3. 如何在不实例化该类的前提下获得对象的某些属性？之所以不想实例化，是因为该对象可能比较庞大，如果对象很多，这会带来显著的性能问题

       有任何问题随时欢迎交流！