一、插件和控件的比较

发布

控件编译到系统中，和系统作为一个整体发布。

插件是在系统的运行过程中动态关联到系统上，可以和系统的其他部分保持物理上的隔离。

控件在系统中的呈现方式在编译时已经确定，通过代码描述控件的表现形式，呈现位置等。

插件的呈现方式在运行的时候根据外部的配置文件指定。

控件作为公用的组件使用，在我们编写业务模块时，控件作为基本资源被我们使用。

插件作为一个独立的业务模块存在，直接面向用户。

控件的调试简单，但插件的调试却比较麻烦。正是因为为了灵活性而制造的隔离措施导致了调试上的困难。通常一个插件作为一个工程开发。

插件是业务模块，就像上面所说的，在我们编写业务模块时控件作为基本资源被使用。所以插件与控件的关系如下图左所示，普通的业务模块如下图右所示。

可以看到，插件是满足一定接口协议的业务模块。

如果一个插件中只有一个控件，并且没有其他的业务逻辑。这种情况下它是插件还是控件？

就像上面所说的，插件是带有一定业务的模块，并且是直接面向用户作为一个系统功能来体现的。插件仅仅是封装了一个控件，并没有带有其他的业务。像这种模块是作为其他插件的子插件使用。如下图所示。

这和我们上面看到的插件内部直接包含控件就不一样了。控件作为子插件的形式被其他插件使用。

插件的配置文件中会将自身的属性作为配置，如标题、图标、和其他一切可以作为配置的元素。但子插件没有详细的配置文件，它的属性直接通过插件的接口暴露给父插件。

这类的子插件是介于插件与控件之间的“伪插件”，因为它并不能独立地在系统中运行，并且通常情况下不带有业务逻辑，不能直接给用户带来价值。

伪插件似乎没有什么好处，谁会无缘无故地在控件之上再封装一层作为插件来使用？

可以想象一下，在系统发布后，我们需要改变某些插件中使用的控件。当然，可以将那些插件全部重新编译后发布。但如果使用这种“伪插件”的思路，我们可以开发一个满足同样接口的另外一个伪插件，并在内部使用不同的控件实现。这样就可以在不发布其他插件的情况下，灵活地修改我们使用的控件了。

如果所有的控件都像上面的来实现，那简直是一场恶梦，并且也没有这个必要。因为这样做的成本比较大。

至于实际中是直接用控件，还是用伪插件的技术，那就要看我们的决策了。