做虚假的插件

做虚假的插件

最近一直在进行下一代CSDN社区的详细设计，其中各个社区都需要有自己的特色，苦恼的地方就是灵活定制和性能的取舍。

插件系统就是相当灵活的系统。

http://www.cnblogs.com/muddle/archive/2004/06/11/4762.html
这里对插件系统的描述就相当不错。摘抄几句：

插件系统就是指 当宿主程序开发好以后，可以开发一些符合自定义规范的程序(插件)，来扩充宿主程序的功能。

插件系统的设计注意点为：
1. 宿主程序如何知道插件的存在；
2. 插件如何从宿主程序获得必需要的内容；
3. 插件之间如何交换信息；
4. 如何对插件进行扩充(也就是说每一个插件都可以作为一个宿主程序)；
5. 考虑插件升级，等其它因素；

要实现以上灵活的插件系统，.net 下使用反射是必然。但是使用反射又有性能的问题。
反射的性能可以参看以下链接：
http://blog.csdn.net/leafwiz/archive/2004/10/18/141882.aspx
http://nickchen.mblogger.cn/posts/28131.aspx

另外，如果每个插件要用到自己的数据库的话，更麻烦。在社区设计中每个插件涉及到数据库就很明显，比如CSDN 社区的积分制可以被认为是一个插件。保存积分就需要数据表。而这个数据表又不是孤立的。

这样灵活的系统下，性能必然成为很大的问题，而社区一般都是众人集中的地方，性能、用户体验是第一要素。

考虑到以上的问题，在CSDN下一代社区开发中，我觉得采用一个中庸取舍方式比较好。

首先这个社区的插件应该都是由我们组织开发的，我们清楚有哪些插件。这样就不需要考虑特别灵活的扩创一个新的插件，而只需要考虑灵活的调用一个插件，同时调用时要考虑性能问题。
这样在新设计一个插件的时候，可能会比较麻烦。但好在这不是第三方完成的，我们是可以控制的。

我们在程序架构上，就可以假设这些插件都是存在的，只是调用不调用的问题。
这其实就变成配置参数的思想，而不再是插件的思想了。

只不过我们为了为了维护方便，仍然采用插件的思想，把每一个插件相关的操作，尽量集中到一个应用程序集中（这里仅仅是尽量而不是强制要求）。部署的时候，方便管理。

这个虚假插件系统中，甚至可能部分插件是混杂在一起的（比如数据库中，宿主数据表和插件用到数据表被集成到一个表中，宿主程序和插件程序对该数据表同一行不同列的操作，可能会被集中到一个函数中完成）。

这就是一个虚假的插件系统。但是他是照顾了性能，又有相当灵活性的。

结论：
以上的中庸取舍思想，其实在软件开发中很有意义，因为我们的实际项目需求，跟某个设计模式的理想状态总是有差别的。

附带说一下：网站的总体性能，总体体验，主要是由用户最常使用的功能决定的，如果你的一个优化把用户最常使用的功能反应速度提高了，而把不常使用的功能反应速度增大了，这仍然是一个好的性能方案。