转载地址：http://guojun2sq.blog.163.com/blog/static/64330861201002010314694/

http://www.cnblogs.com/mix-up/archive/2009/12/31/1636608.html

基于插件式的开发框架

基于插件式的开发框架: 源码  

2010-01-20 22:03:14|  分类： 插件|字号 订阅

在此源代码发布后很多朋友提出了一些设计和技术方面的问题, 在本篇下方的评论处本人对其依依做了解答, 虽不能保证解答的正确性, 但强烈建议您去阅读一下.

插件式以其身优势广为开发者所喜爱，本人参与开发过的几个项目都用到了插件式的概念。

最近几天不是很忙， 抽空重新梳理了一下逻辑， 将业务部分剥离， 便有了此版的插件式的开发框架。

希望通过此代码能与大家交流技术，探讨问题，也希望大家提出宝贵意见。

- 概念

 插件: 插件是可独立完成某个或一系列功能的模块.通常插件由宿主程序加载，不能独立运行。

 宿主: 宿主是承载插件运行的环境，为插件提供基本服务。通常插件由宿主程序管理和控制。

插件式: 通常是由开发人员编写宿主程序,并预先定义好系统提供基本服务接口和插件接口。然后由其他开发人员根据系统插件接口编写插件功能。通常插件以一个独立功能模块的形式出现。对于宿主程序来说并不知道插件的具体功能，通常宿主启动时检索插件信息，并根据预定的插件接口装载插件。

- 优势

增强系统扩展性: 在系统发布后可在不必重新编译系统的前提下按需对系统功能进行扩充。

易维护及复用性: 插件通常为独立的功能模块易于管理与维护，并可在多个业务系统中重用。

如果了解了以上这些信息那么就不难阅读这份源码了。

声明: 此代码仅为学习之用, 可自由转载或使用, 但希望使用者尽量保留文件头部信息以保证后续开发者能及时反馈.

项目结构

主要类型及接口

IHost 宿主接口PackageHost 插件宿主抽象类(此抽象类实现IHost接口,并提供插件管理功能. 定制基于业务的插件宿主应从此类继承)IPackageServiceProvider 插件服务提供者接口(由此接口实现者提供插件服务)DictionaryServiceProviderAdapter IServiceProvider接口适配器(提供从Dictionary到IServiceProvider的转换)IPackageProvider 插件提供者接口(由此接口实现者提供插件源)FilePackageProvider
文件插件提供者实现IPackageManager 插件管理器接口PackageManager 插件管理器实现IPackageController 插件控制器接口PackageController 插件控制器实现IPackage 插件接口(由此接口实现插件功能)
目录结构

__
│  
│  Addin.sln
│  
├─Addin
│  │  Addin.csproj
│  │  IConfigurationInitialize.cs
│  │  IHost.cs
│  │  IPackage.cs
│  │  IPackageController.cs
│  │  IPackageProvider.cs
│  │  IPackageManager.cs
│  │  IPackageServiceProvider.cs
│  │  PackageController.cs
│  │  PackageControllerCollection.cs
│  │  PackageDescription.cs
│  │  PackageHost.cs
│  │  PackageManager.cs
│  │  
│  ├─adapter
│  │      DictionaryServiceProviderAdapter.cs
│  │          
│  ├─common
│  │      CancelEventArgs.cs
│  │      EventArgs.cs
│  │      
│  ├─configuration
│  │      AddinSection.cs
│  │      
│  ├─provider
│  │      FilePackageProvider.cs
│  │      
│  └─utility
│          Guard.cs
│          
├─Addin.HostDemo
│  │  Addin.HostDemo.csproj
│  │  Addin.HostDemo.csproj.user
│  │  FormHostManager.cs
│  │  HostForm.cs
│  │  HostForm.Designer.cs
│  │  HostForm.resx
│  │  Program.cs
│  │  
│  ├─adapters
│  │      CommandBarItemCollectionAdapter.cs
│  │      CommandBarManagerAdapter.cs
│  │      CommandBarMenuAdapter.cs
│  │      StatusBarAdapter.cs
│  │              
│  ├─packages
│  │      Addin.PackageDemo.dll
│  │      Addin.PackageDemo.dll.config
│  │      
│  └─Properties
│          AssemblyInfo.cs
│          
├─Addin.PackageDemo
│  │  Addin.PackageDemo.csproj
│  │  App.config
│  │  Form1.cs
│  │  Form1.Designer.cs
│  │  Form1.resx
│  │              
│  └─Properties
│          AssemblyInfo.cs
│          
└─Addin.Services
│  Addin.Services.csproj
│  ICommandBar.cs
│  ICommandBarCollection.cs
│  ICommandBarItem.cs
│  ICommandBarItemCollection.cs
│  ICommandBarManager.cs
│  ICommandBarMenu.cs
│  ICommandBarSeparator.cs
│  IContainer.cs
│  IStatusBar.cs
AssemblyInfo.cs

发表评论
@xiaosuo
嘿..你猜..
(源码很重要,但理念更重要. 源码请在贴子中查找..)
插件式的加密混淆是个问题，新旧插件非要一起混淆才能用。楼主真不考虑混淆问题么？你的软件全部开源？
@ganquan
你的软件全部开源？
"开源"这词实在不敢当,本贴意在探讨设计而非代码本身.个人觉得思想才是难以跨越的障碍,至于代码实在没什么技术含量.

插件式的加密混淆? 
不好意思,我没太理解这句,暂且我先认为是代码的加密.
上面的问题我已解释了,就我个人而言不觉得这份代码有多"珍贵".所以本人忽略代码的加密.. 呵.. 
至于插件部分就取决于插件开发者了.

@Jack Fan
@疯流成性
稍后我会抽空写一些此框架开发过程中的小经验.但初于本人表达能力较差,所以此过程可能会有点长,期待介时能与二位交流想法.
感谢二位的支持.
楼主，请教一个问题，你现在这个框加是 主程序一启动，就加载程序，
那如果我要 按需加载怎么做，（就是操作到这个模块的时候才加载这个模块），不然，模块多了，我想主程序启动的时候会很慢，而且还要加上权限的控制。
插件平台对我来说也非常有吸引力，本人也开发了一个插件平台，目前正在优化，一旦优化完成也将开源。

一个插件平台至少需要考虑：（1）用户如何开发、调试、部署插件？（2）插件平台和插件的结构；（3）插件间的依赖与通讯；（4）插件的多版本问题和类加载机制；（5）插件的扩展；（6）按需加载。（附：此外，我们还需要考虑到WinForm、WPF、Web、RIA不同应用的插件平台）

此外，还有很重要插件隔离以及安全性。不过，只是在.NET，要实现隔离就得使用AppDomain，而跨AppDomain会带来很大性能损失，因此我暂时不考虑多个AppDomain。安全性比较重要但目前对我而言不是最紧急的。

对我来说，一个插件平台最大的优点在于模块化，模块化就是从横向来切割应用系统，从而使每个插件的开发都很简单。

不知楼主是否考虑到这些问题，且如何解决的。
只要看lz用assembly.Loadfrom还是appdomain.Create 就知道这个插件的水平了。

公布核心代码吧。
说些个人感受的空话，插件技术和插件框架核心在于模块化/组件化，模块化核心在于高内聚、低耦合，插件框架是模块化设计到一定阶段的必然且必须的产物，插件框架做的更好就一定要参考osgi规范。有了插件框架更大的难度同样也是如何将系统更好的模块化/组件化。
好像微软开源社区已经有插件框架的开发计划。
@辰

我不想用LoadFrom，也不想用AppDomain.Create。我想用LoadFile。：）

AppDomain提供了物理隔离，但性能不行。因此，我不用隔离，但想支持多版本。MAF提供了物理隔离，SharpDevelop没有提供。

@dicky
@道法自然

我看了核心代码，是

Assembly assembly = Assembly.LoadFrom(fileName);

那么基本上来说，这个插件是cs模式下的，而且是应用程序，不是服务程序。

因为assembly.load是不可能卸载的。除非关系统。我的插件框架用了appDomain，因此可以直接热插拔，直接卸载。

lz仍需努力。
引用辰：
我看了核心代码，是Assembly assembly = Assembly.LoadFrom(fileName);那么基本上来说，这个插件是cs模式下的，而且是应用程序，不是服务程序。因为assembly.load是不可能卸载的。除非关系统。我的插件框架用了appDomain，因此可以直接热插拔，直接卸载。
lz仍需努力。

刚吃过午饭回来,看到这么多人关注很是兴奋. :) 

那么我来解答你的问题.
先说 Assembly.LoadFrom(fileName):
如果我没记错的话这句代码出现在 FilePackageProvider 中,在此框架中 FilePackageProvider 实现了 IPackageProvider 接口. 在此框架设计中 IPackageProvider 应是由框架使用者现实的, FilePackageProvider 只是本框架内提供的默认实现,当然你可以定义你自己的 IPackageProvider 实现, 然后在 PackageHost 构造时将其"注入"(详见代码 Addin.HostDemo.Program 处).简单点说,你觉得
Assembly.LoadFrom(fileName) 不合适的话可以实现自己的 IPackageProvider.

再来说插件卸载:
由于时间比较紧所以此贴没对设计细节做过多介绍,但如果详细查看源代码就不难发现 IPackageManager 接口与此接口的实现 PackageManager, 其中包含两个相关方法 void RegistryPackage(string packageZipFileName); void DeletePackage(Guid packageId);意在注册插件与卸载插件. 因为此版是preview,所以你会发现 PackageManager 并未对这两个方法提供功能实现,而是定义为virtual,意在预留子类实现.那么也就是说在设计之初对插件卸载是有所考虑的,并且此处未实现还有一个原因--我一直在权衡是否将这两个方法放到
IPackageProvider 中.

从你所提到的这2个问题来看,我们俩所讨论(关注)的并非同是一层面的东西.你所提到的建议我会认真考虑,希望继续交流..感谢..

@fancycloud
不好意思,看来是我没有表达清楚.
如果查看代码你就会发现, 主程序启动并没有"加载"(实例化)插件,而只是获取了插件描述信息(见代码中PackageDescription).
具体的插件实例化过程应是由后续开发者决定的. 如 Addin.HostDemo 中是通过点击菜单项后实例化并启动插件的.

P.S. 此问题不属于框架解决的范畴,何时实例化插件应由具体业务实现时决定.

权限的控制: 可在 IPackageManager 的 PackageAdding 事件中作相应权限控制, 并可在适当条件下取消 IPackage 的注册操作.
@道法自然
看到您所提到的问题就知道您才是行家.望多交流..
（1）用户如何开发、调试、部署插件？
见代码 Addin.HostDemo,Addin.PackageDemo,Addin.Services部分
（2）插件平台和插件的结构；
忘记标明此代码是基于.net framework2.0构建的
（3）插件间的依赖与通讯；
我对插件的理解见文中[概念]处[插件]段 -- "插件是可独立完成某个或一系列功能的模块.通常插件由宿主程序加载，不能独立运行。",如果我理解的没错的话,我也提出一个问题:即然是独立的功能模块那何谈与其它插件的依赖? 如果您的意思是插件间"数据依赖"的话那我们再继续探讨.
（4）插件的多版本问题和类加载机制；
见23楼.
（5）插件的扩展；
这问题似乎和上一个很像..（4）
（6）按需加载。
见24楼.

个人知识面有限,设计中不合理或理解有误之处还望继续指证与探讨. 感谢..
仔细拜读了下作者的文章，说实话感觉理论知识还是很不错的，但是我并不赞同你的结构设计。首先，插件没必要非设计成这样复杂的结构，还需要HOST，感觉虽然文笔不错，理论知识很好，但是可行性较差。 我最认同的还是人家QQ2009的插件模型，有机会还望您去研究下，可能我有点说过了，但是您那样的插件方式 实在是让我接受不了。 以上之言 仅代表我个人的看法，如有得罪，请见谅。
@dicky

整个插件核心应该就是这个IPackageProvider啊。lz仔细想想看看。

其他的可以说基本上是废码，不是说没用的代码，而是不是插件这个框架特有的。

什么packagemanager之类的，我用最sb的List+interface都可以实现。

不过lz也别觉得我说的不是问题。您要把FilePackageProvider改成支持appdomain的，几乎要花掉您另外50%的工作量。

就是说您开发一个addin框架和开发一个支持appdomain的功能难度是相当的。
@剑走偏锋[E.S.T]
呵, 说的不过. 
HOST译为宿主,不要理解为主机哟. 
至于"复杂的结构"您可查看下我在 #8楼 和回复. 感谢,希望多交流..
基本上来说，如果把“插件”这个概念抛弃。lz只是实现了一个轻量级的基于接口的设计模式，也不算是spring，因为还没有实现松耦合。

等引入了xml配置，运行时加载之后就是一个简单的spring。

等引入了appdomain之后，才能算是插件框架。
引用辰：
整个插件核心应该就是这个IPackageProvider啊。lz仔细想想看看。
其他的可以说基本上是废码，不是说没用的代码，而是不是插件这个框架特有的。
什么packagemanager之类的，我用最sb的List+interface都可以实现。
不过lz也别觉得我说的不是问题。您要把FilePackageProvider改成支持appdomain的，几乎要花掉您另外50%的工作量。
就是说您开发一个addin框架和开发一个支持appdomain的功能难度是相当的。

整个插件核心是 PackageManager.(稍后我会对此写一说明性文章)
在设计此框架时我认为 IPackageProvider 是个变化点,框架不应该强制 PackageProvider 只是从文件加载插件,试想如果这个插件是其它程序提供的对象呢? 所以更好的办法是让后续开发者决定从哪里加载和如何加载插件. 

个人觉得对于称之为框架的项目来讲功能很重要,职责的划分也很重要,但拥有足够的扩展空间似乎更是重中之重.如果没有足够的扩展那就不应该叫做框架了,貌似应该叫"工具"(这句是我乱说的,嘿)..

很希望能有机会拜读一下您提到的支持appdomain功能的PackageProvider.. 期待..

"基本上来说，如果把“BMW X6”这个标志抛弃。它只是一个外表好看的四轮驱动的汽车，也不算是富田小卡，因为还没有车后箱。"
呵.. 开个玩笑..

可能我对这个框架没有足够的功能描述导致您的一些疑惑,稍后我会对它进行一些简要介绍,期待与您进一步讨论.. 再次感谢.. 

@dicky

固执是件好事 也是件坏事

咱们磨磨嘴皮子 也就是打发一下时间 增添一些生活情趣 不过lz将来能走多远 就要看lz了。

期待lz的下文
引用dicky：
@道法自然
看到您所提到的问题就知道您才是行家.望多交流..
（1）用户如何开发、调试、部署插件？
见代码 Addin.HostDemo,Addin.PackageDemo,Addin.Services部分
（2）插件平台和插件的结构；
忘记标明此代码是基于.net framework2.0构建的
（3）插件间的依赖与通讯；
我对插件的理解见文中[概念]处[插件]段 -- "插件是可独立完成某个或一系列功能的模块.通常插件由宿主程序加载，不能独立运行。",如果我理解的没错的话,我也提出一个问题:即然是独立的功能模块那何谈与其它插件的依赖? 如果您的意思是插件间"数据依赖"的话那我们再继续探讨.
（4）插件的多版本问题和类加载机制；
见23楼.
（5）插件的扩展；
这问题似乎和上一个很像..（4）
（6）按需加载。
见24楼.

个人知识面有限,设计中不合理或理解有误之处还望继续指证与探讨. 感谢..
（1）用户开发方式或许是A）插件平台正在运行，你创建一个工程到指定目录；B）用户开发插件需要引入插件平台工程。这涉及不少的小细节。
（2）结构是指，比如插件平台有几个文件夹，哪个文件夹是放置插件库，每一个插件的结构又是如何。
（3）独立运行不代表没有功能上的依赖，这种依赖可以是，A）插件A在运行过程中使用插件B的功能；B）插件A在开发过程中可能需要从B加载一个可复用的类。
（4）如果两个插件引用了同一程序集的不同版本，如何解决？
（5）插件的扩展，是指一个插件可以对另一个插件进行扩展。

当然，要设计好一个优秀的插件平台是没有那么容易的，需要从很多方面进行综合考虑。但不管怎样，都必须先从用户角度来考虑，提供什么功能，用户怎么使用这些功能。

至于有朋友提到的，引入AppDomain确实实现了插件的隔离性和可卸载，但是性能、复杂度和适应性大打折扣。如果没有隔离性的话，在大型应用的话，安全性和可靠性比较难以保证了。

.NET没有像Java中灵活的ClassLoader，因此，我们需要做一些衡量。

引用道法自然：
（1）用户开发方式或许是A）插件平台正在运行，你创建一个工程到指定目录；B）用户开发插件需要引入插件平台工程。这涉及不少的小细节。
（2）结构是指，比如插件平台有几个文件夹，哪个文件夹是放置插件库，每一个插件的结构又是如何。
（3）独立运行不代表没有功能上的依赖，这种依赖可以是，A）插件A在运行过程中使用插件B的功能；B）插件A在开发过程中可能需要从B加载一个可复用的类。
（4）如果两个插件引用了同一程序集的不同版本，如何解决？
（5）插件的扩展，是指一个插件可以对另一个插件进行扩展。

当然，要设计好一个优秀的插件平台是没有那么容易的，需要从很多方面进行综合考虑。但不管怎样，都必须先从用户角度来考虑，提供什么功能，用户怎么使用这些功能。

至于有朋友提到的，引入AppDomain确实实现了插件的隔离性和可卸载，但是性能、复杂度和适应性大打折扣。如果没有隔离性的话，在大型应用的话，安全性和可靠性比较难以保证了。

.NET没有像Java中灵活的ClassLoader，因此，我们需要做一些衡量。

请查看我的另一篇文章了解一下什么叫"开发框架". 

http://www.cnblogs.com/mix-up/archive/2010/01/01/1637437.html

开发框架,有所关注,有所不关注,请注意我文章使用的标题,再次重复一下是"基于插件式的开发框架".

基于插件式的开发框架: (1)概念及意图  

2010-01-20 22:18:38|  分类： 插件|字号 订阅

  新的一年开始了, 首先祝大家心想事成, 万事如意!

在上一篇文章(基于插件式的开发框架: 源码)中发布了近期写的一个框架源码, 值得兴奋的是很多人都参与到了讨论, 并提出了宝贵意见.

由于发布源代码之初未对其框架设计做过多说明, 所以可能导致大多数人对这个框架产生了一些疑惑. 那么本人就此对框架做个介绍, 希望大家能从中更进一步了解本框架的设计初衷, 也希望能与大家交流想法.

在上一篇文章中我对插件式的概念做了个总结(如下), 意在大家能对插件式从概念上有个初步了解.

插件: 插件是可独立完成某个或一系列功能的模块. 通常插件由宿主程序加载, 不能独立运行.

宿主: 宿主是承载插件运行的环境, 为插件提供基本服务. 通常插件由宿主程序管理和控制.

插件式: 通常是由开发人员编写宿主程序, 并预先定义好系统提供基本服务接口和插件接口.然后由其他开发人员根据系统插件接口编写插件功能. 通常插件以一个独立功能模块的形式出现. 对于宿主程序来说并不知道插件的具体功能, 通常宿主启动时检索插件信息, 并根据预定的插件接口装载插件.

但基于上一篇文章评论中大家提到的一些问题, 我觉得有必要再来介绍一下开发框架的概念.

开发框架(也可称其为框架): 开发框架是一个具有部分功能的应用程序半成品, 它提供了可在应用程序之间共享的可复用的公共结构. 后续开发者把框架融入到自己的应用程序中, 并加以扩展以满足他们特定的业务需要. 通常框架是成熟的、不断升级的软件. 框架是一个可复用的设计构件, 它规定了应用的体系结构、阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程,最终表现为一组抽象类以及其实例之间协作的方法.

如果您了解了以上这些概念, 我想从文章中的标题("基于插件式的开发框架")中就应该大体上了解了它要做的工作. 在了解这两个关键概念(插件式,开发框架)基础上, 我会在稍后的几篇文章中陆续与大家分享我在这份源码设计开发过程中的思路和想法.

此框架的设计意图
我想如果没有前面提到的"概念"部分, 可能会有一些人不明确这个名为<基于插件式的开发框架>的东西要干什么. 这也是我把概念部分放到顶端的原因--希望它对理解这个框架的意图能有所帮助. 那就本插件式开发框架来说结合以上概念, 其实我们是要编写一个能阐明协作构件之间的依赖关系、责任分配和控制流程的、可复用的、具有部分功能的插件宿主, 并预先定义好扩展接口供后续开发者使用.

虽然前面写了很长的"铺垫", 但一时间似乎仍不太容易理解意图本质, 不过没关系在稍后几篇中我会逐步细化每一个过程.

基于插件式的开发框架: (2)责任分配  

2010-01-20 22:35:37|  分类： 插件|字号 订阅

公司里有两部电话, 是用来做支持的, 一个是技术方面的, 一个是业务方面的. 客户会
打电话过来咨询一些问题. 但是, 出现一个小问题, 客户通常分不清他要问的问题是业
务的还是技术的, 所以总是会打错电话. 公司内部麻烦不说, 造成客户满意度直线下降. 
后来领导要求将两部电话换成一部, 这样就避免了客户打错电话的问题. 但事情并没有
到此结束, 由于技术部和业务部日常工作都比较繁忙, 电话换成一部后时常无人接听, 
原因很简单, 技术部的人想, 电话可能不是咨询技术问题的, 让业务部的人接听去吧, 
业务部的人的想法异同. 领导了解到情况后, 立即部署"专职人员"专注电话接听工作, 
从此电话接听问题得到了解决.
以上是一个简单案例, 从中我们可以看出责任分配不明确所带来的一些影响.
再回到插件式开发框架部分, 简要说下本框架是如何进行责任分配的.
上一篇意图中很明确的目标是构造宿主程序, 又从基本概念中了解到宿主是管理和控制
插件的, 那么框架中宿主内部各构件的责任如何分配似乎已显现出了大半.
插件管理(源码中IPackageManager)
插件管理即对装载插件,注册插件,移除插件等操作的管理. 
插件控制(源码中IPackageController)
插件控制即对运行(启动)插件,停止(卸载)插件进行控制.
前两篇文章的评论中有人说你这个开发框架"什么packagemanager之类的，我用最sb的
List+interface都可以实现。". 那么我希望能通过上面的案例说明我在此框架中使用
packagemanager的原由 -- 每件事物都应有"专职人员"处理.
公司里有两部电话, 是用来做支持的, 一个是技术方面的, 一个是业务方面的. 客户会打电话过来咨询一些问题. 但是, 出现一个小问题, 客户通常分不清他要问的问题是业务的还是技术的, 所以总是会打错电话. 公司内部麻烦不说, 造成客户满意度直线下降. 后来领导要求将两部电话换成一部, 这样就避免了客户打错电话的问题. 但事情并没有到此结束, 由于技术部和业务部日常工作都比较繁忙, 电话换成一部后时常无人接听, 原因很简单, 技术部的人想, 电话可能不是咨询技术问题的, 让业务部的人接听去吧, 业务部的人的想法异同.
领导了解到情况后, 立即部署"专职人员"专注电话接听工作, 从此电话接听问题得到了解决.

以上是一个简单案例, 从中我们可以看出责任分配不明确所带来的一些影响.

再回到插件式开发框架部分, 简要说下本框架是如何进行责任分配的.

上一篇意图中很明确的目标是构造宿主程序, 又从基本概念中了解到宿主是管理和控制插件的, 那么框架中宿主内部各构件的责任如何分配似乎已显现出了大半.

插件管理(源码中IPackageManager)

  插件管理即对装载插件,注册插件,移除插件等操作的管理. 

插件控制(源码中IPackageController)

  插件控制即对运行(启动)插件,停止(卸载)插件进行控制.

前两篇文章的评论中有人说你这个开发框架"什么packagemanager之类的，我用最sb的List+interface都可以实现。". 那么我希望能通过上面的案例说明我在此框架中使用packagemanager的原由 -- 每件事物都应有"专职人员"处理.

发表评论
就这么几个字？就IPackageManager和IPackageController这两玩意，每个各一行解释？然后起了个响亮的名字“责任分配”？

要做的话，做好一点，专业一点。当然包括你写的内容，要公开的话，就大大方方漂漂亮亮的公开，如果不公开，干脆什么都不写，以免被认为是遮遮掩掩。都不知道是你实际水平不高，还是写作水平不高，还是故意遮遮掩掩。

当然，这是我个人的评论，你可以不接受。
引用道法自然：
就这么几个字？就IPackageManager和IPackageController这两玩意，每个各一行解释？然后起了个响亮的名字“责任分配”？

要做的话，做好一点，专业一点。当然包括你写的内容，要公开的话，就大大方方漂漂亮亮的公开，如果不公开，干脆什么都不写，以免被认为是遮遮掩掩。都不知道是你实际水平不高，还是写作水平不高，还是故意遮遮掩掩。

当然，这是我个人的评论，你可以不接受。

1.内容的多少似乎和表达的思想没有直接关系吧?
2.我讲的不是"责任分配"的内容吗?这也太霸道了吧,用个名词都是罪?
3.什么是好?什么是专业?请发布你所谓专业的代码或文章让大家看看.
4.源代码都放出来了请你告诉我,"掩"哪里?
5.你觉得没看懂可以讨论,但请明确一点,ME不是来这比水平高低的.所以你的"都不知道是你实际水平不高，还是写作水平不高"我没法给你一个答案.恩,ME的写作水平一般,这点ME接受.(说这话并没有表示技术水平高的意思..得说明一下,免得再挨训.. -_-!)

@道法自然

现在博客园就是你这种人越来越多了,说话刻薄，最终弄的整个博客园就那么几个人跳来跳去，还分帮结派。
看上去是维护了整个首页的质量，实际上冷了我们这批新手的心。

另外博主的这个框架写的其实挺不错的，他的源码都放出来了，代码的质量至少在博客园也算比较好的了，你有看过么？

对于说话刻薄者，可以无视不予理会。
该吃吃，该喝喝，遇事别往心里搁，泡泡澡，看看表，舒服一秒是一秒！
你的源码我稍微浏览一下，看了一下结构和几个名词，于是我就没有多看了。我是被“责任分配”这四个字吸引的，因为我从来没有看到其它插件平台提到过这四个字。不过，进来看了就大失所望。

就这么几个字？就IPackageManager和IPackageController这两玩意，每个各一行解释？然后起了个响亮的名字“责任分配”？
>> 你可以指出我所说的这些话错在哪，本文不就是提一下两个类的用途。至少你稍微认真的谈一下要让人知道什么，原理吗？不是。

要做的话，做好一点，专业一点。当然包括你写的内容，要公开的话，就大大方方漂漂亮亮的公开，如果不公开，干脆什么都不写，以免被认为是遮遮掩掩。都不知道是你实际水平不高，还是写作水平不高，还是故意遮遮掩掩。
>> 遮遮掩掩不是指代码公开了就不是了。既然你说的思想重要，那就谈一下你的思想。不过，你都以代码就是思想为由不提，因此你要么是写作不行，要么是理解不到位，要么就是不想写。你可以否定，但是我这样指出来对你没有坏处。当然，这也或许是因为不认真造成的假象。

我没有公布什么源代码，除了一个应用的代码之外，不过，我很认真的公布了我开发组件的思想。源码没有公开是因为我目前做的还不到位，注释、缺陷、易用性等方面还不够完善。

打击你不会给我带来什么好处的。不过，估计你经验不多，不管是代码经验还是对自己的认识（即自知之明），所以我直接说出了我看到内容的想法。

我也说了，你可以接受，也可以不接受。
补充一点：如果要做自己的东西，应该要学会换位思考。换位思考可以简化为，写的文章别人怎么理解，有什么收获。从而，也可以知道，做的东西别人怎么用，他们嫌不嫌麻烦？如何改进。

我也只是一个菜鸟，不专业。不过，至少觉得这文章写的不太认真，有点凑数的意思。下文是一个专业人士写的一篇文章。

http://sardes.inrialpes.fr/~krakowia/MW-Book/

@道法自然

首先,请认真阅读本博客中以"基于插件式开发框架"字样开头的文章,或者先自己弄明白什么叫"上一篇".先弄明白基本的东西再来评论,不要认为所有名称中带有"插件式"字样的都得和你认为的"插件式"扯上关系.

-------
我是被“责任分配”这四个字吸引的，因为我从来没有看到其它插件平台提到过这四个字。不过，进来看了就大失所望。

你去过北极么?.. 不懂什么是“责任分配”请看上一篇文章.

-------
就这么几个字？就IPackageManager和IPackageController这两玩意，每个各一行解释？然后起了个响亮的名字“责任分配”？
>> 你可以指出我所说的这些话错在哪，本文不就是提一下两个类的用途。至少你稍微认真的谈一下要让人知道什么，原理吗？不是。

首先,请看上一篇文章.
其次,本文是结合源代码对其进行介绍(上一篇中已有说明).
再次,别告诉我你没看懂文章中例举的案例,也不要再SS的说是为了看“责任分配”四个字进来的,否则这个评论我只当YRYY.

-------
要做的话，做好一点，专业一点。当然包括你写的内容，要公开的话，就大大方方漂漂亮亮的公开，如果不公开，干脆什么都不写，以免被认为是遮遮掩掩。都不知道是你实际水平不高，还是写作水平不高，还是故意遮遮掩掩。
>> 遮遮掩掩不是指代码公开了就不是了。既然你说的思想重要，那就谈一下你的思想。不过，你都以代码就是思想为由不提，因此你要么是写作不行，要么是理解不到位，要么就是不想写。你可以否定，但是我这样指出来对你没有坏处。当然，这也或许是因为不认真造成的假象。

除了你所说的"IPackageManager和IPackageController这两玩意"外,文章开头与结尾部分不是"小夜曲"..

-------
我没有公布什么源代码，除了一个应用的代码之外，不过，我很认真的公布了我开发组件的思想。源码没有公开是因为我目前做的还不到位，注释、缺陷、易用性等方面还不够完善。

是那篇<总结：我喜欢的软件体系结构——分层、模块化与OSGi>么?
的确文章内容比我的长,但仔细看下更像是对各"技术"的介绍.
"我以前喜欢追求有艺术的代码，什么是有艺术的代码呢？那就是要有技术含量，殊不知，简单就是艺术！"--是你总结的么,似乎很有深度.
没有注释,存在缺陷,易用性差都没关系,能发给ME一份么我学习一下.
我的邮箱: free-mouse@hotmail.com

-------
估计你经验不多，不管是代码经验还是对自己的认识（即自知之明）

请查看浏览器地址栏上的地址是不是www.cnblogs.com, 这里是博客园技术社区. (P.S. 评论别人的人品是不道德的)

-------
英文文章看不懂,能帮忙给翻译成中文么?.. 谢谢.

毫不畏惧，再变态也不够变态群的人变态
菜丁 加油！！
觉得有水平、看了有收获就“赞一下，捧个场”，觉得不咋样就飘过算了，也或简单的给些建议也算是指点指点人家，干啥把板砖拍得这么凶呀，搞得一点也不和谐，不利于安定团结！

我没有必要说太多了。我花了大约45分钟看了你的代码（原来只是看了一下名词，一般来讲，小的细节就可以看出一个人或代码的质量）。大体逻辑应该如下：
（1）这个框架的结构是IHost =1:N with IPackageServiceProvider=> IPackage，利用预先定义的服务接口实现Host和Package的交互。这种方式类似于WF中的Service。
（2）Host通过使用IPackageManager对所有的Package进行管理，PackageManager使用PackageProvider遍历获取所有的PackageDescription，然后为每一个Package创建一个PackageController并保存起来。
（3）每一个特定的应用都必须实现其特定的Host和ServiceProvider，以及若干Package。Host将以独特的方式来使用每一个插件，它们的交互利用特定的服务实现交互。就比如WinForm的插件应用，大概是主窗体实现IHost，然后利用辅助类创建插件，在某个动作触发时，去加载或者卸载插件。在例子，你用了一个Tag来存储对应的插件名称（我2005年实现的通用窗体框架也采用这种狡猾的方式），然后利用这个Tag加载/卸载插件。
（4）对于你的例子，我没有太多的时间和精力仔细看。不过大体猜测的出来。

因此，我感觉你用一篇的篇幅就可以把这个框架的内容描述清楚了，不至于用那么多的篇幅，特别是像这一篇没有两句话的文章。

优缺点我觉得我已经没有必要再说太多，你觉得你的框架好就行。忠言逆耳，实在的话总是不太好听的。我原来说的不好听的话呢，你不用接受。我收回我说过的话。

此外，再辩解一句“估计你经验不多，不管是代码经验还是对自己的认识（即自知之明）”，此话不是想攻击人品，不过，我承认，我在说这句话的时候，自大了，觉得我应该比你经历的事情多，这是我的错。我只是想说的是，每个人最好都有对自己的优缺点有所认识，从而能够更好的吸取别人的优点，因此，必须有自知之明。我也有自知之明，那就是我属于菜鸟，比较笨，属于反应迟钝型，一般都会比别人反应晚一步。

至于可以拿得出手的代码，我暂时不方便给你，因为这些代码给我带来了若干倍于上班的收入，我自己的公司不允许我现在这么做，我们有我们的开源计划，需要依赖这个计划给我们带来更多的保障。不过，我可以说一下我们组件开发方法：（1）用户场景设计，即考虑好用户如何使用这个组件，其好处是我们可以根据场景不断优化用户的应用，从而达到简单是美的原则，这个原则是对用户而言的；（2）必须有全部接口的类图，VS里面的类图非常的方便，Eclipse里面就稍微麻烦一点；（3）有重要的设计规范；（4）有API说明书，这个可以通过文档工具自动生成，因此需要对公开接口进行完善的注释；（5）基于SVN代码管理；（6）单元测试和集成测试。其实本来还应该具有完善的用户指南、缺陷管理和持续集成，但是我们只是在下班时间做这些东西，没有足够的时间。
道法自然兄弟就别认真了。上次我也说过了。不过lz似乎非常的坚持。

说白了lz的东西就是个设计模式，不过感觉也不知道是什么模式。

不过lz当技术人员比较适合。缺少跳跃思维，1+1=2，一步一步逻辑性强。不适合做manager类。

如果lz长期坚持下去，会是一个很专的engineer。但是稍微跨跨行业就完蛋了。而且也有可能专长的方向被淘汰之后，出现危机。
List<T> = IPackageManager 
interface = IPackageController

这样做个稍稍跳跃性类比不知道是否能够说明白问题。

List<T> 是个class，只不过是微软写的一个class。如果微软把List<T>命名为PacakgeManager<T>。那么lz会不会更加的清晰？
几句争论最终沦为“忠言逆耳，实在的话总是不太好听的。我原来说的不好听的话呢，你不用接受。” 俗……
@辰
@道法自然
很高兴 @道法自然 能抽出45分钟去看我的代码,你所指出的1,2,3点也基本描述了这个开发框架的工作流程, 但描述流程并不是写这几篇文章的本意, 流程只能让人知道如何使用. 而我是希望能让其它人了解到设计中的一些思想和经验. 当然, 我要承认自己的写作水平较差, 一些想法可能表达的不够清楚, 但意图是明确的.

我一直认为在讨论中学习是个不错方式, 我也很高兴能和大家探讨, 但这需要建立在交流学习的心态之上. 但你2楼的回复实在让人难以接受, "小菜鸟经不起大板砖", 望你能理解. 

在技术社区里说太多与技术无关的没意义,那回到技术,我简要说下 你和@辰 我们对这个开发框架的分歧之处.

你的上面的回复基于说出了这个开发框架的工作流程与关键要素,说白它就是装载插件,然后让后续开发者能够方便的管理与控制插件.

对于此开发框架来说,它没法预知到后续使用者所使用的宿主类型(窗体程序/控制台程序/其它),所以使用了抽像类型PackageHost, PackageHost中封装检索插件操作,并提供插件管理访问点,后续开发者由此抽象继承,从而获得插件管理功能,并且不阻碍他对宿主类型的选择,让后续开发者有足够的扩展权.

像宿主类型一样,在设计此框架时我认为插件的来源也是无法预知的,框架不应该强制只是从文件加载插件,试想如果这个插件是其它程序(服务)提供的对象呢? 所以它也应该由后续开发者决定从哪加载和如何加载,仔细查看代码你会发现PackageHost构造时是可以"注入"自己的IPackageProvider的,而FilePackageProvider只是框架中的默认实现方式,对于简单应用它已经足够了,当然如果有复杂应用的比如你前些时候回复中提到的"两个插件引用了同一程序集的不同版本"等你可以实现IPackageProvider定制基于自己需求的插件提供者.但对于本框架来说这部分是不被关注的,它应该由后续开发者决定.
这也是你和@辰我们的分歧之处.

@辰 所说的问题本文正文处已给出了解释,本开发框架的客户(后续开发者)必须有明确的访问点(两部电话与一部电话的问题),同时框架本身也应明确谁来做什么事(有"专职人员"专注电话接听工作).我不否定@辰提到的List+interface,但是我觉得使用PackageManager能更好的显现其职责,并有利于后续开发者的使用.

写的有点长, 但由于本人表达能力原因, 我依然没法确定此段文字是否能被大家所理解, 技术方面的不明之处请继续探讨. 感谢各位.

@Ling2008
@FrankYu
感谢二位的支持与理解.
@别爱上哥，哥只是个传说！
恩,下次我努力写的丰富些. 感谢..
@dicky
我应该宽容点，这是我的错。关于你FW的设计，默认实现及其预留的一些扩展，我能理解，Core的代码我已经都看完了。我对你的代码和你说的都能理解，只是你不知道我的意思。每个人长的都差不多，想的也差不多，这是人性。FW一般思路都是“抽象——默认实现——扩展”，只不过存在好与坏的区别而已。我虽然说了不讨人喜欢的实话，不过，你不用在意，自己认为自己的FW好就行了。不拘小节，注意细节。其它话，包括对这个FW的评价，我就不再说了。