这已经是本系列的第四篇了,以前我多数时间是看文章,自己写起来才感觉到当博主不容易啊,所以我们无论评论也好,阅读也好,都要尊重博主的劳动成果。闲话少说,在这篇文章中我们将对BlogEngine.Net的全局配置进行一下分析与探讨。关于配置这一部分单独拿出来做一篇文章实在有些牵强,但是我总觉得这个配置部分比较独立,而且BlogEngine.Net的设计和实现都有很多可以参考的地方。
在一个企业级应用系统中,对一些系统全局参数进行配置是必不可少的,那么我们是怎么处理这些配置的呢?
一般都有以下三步:
1.在业务模块开发的过程中将一些可变的参量提取出来。
2.当所有业务模块开发完成时,将这些参量分类存储起来。
3.开发出相应的管理功能,允许用户对这些参量进行设置。
相信大多数开发者都是直接操作数据库中的数据,可能有些比较完善的系统会做出单独的页面来给用户管理使用,本质上也都是直接与数据库打交道,没有涉及太多的逻辑,比较直接。不过在BlogEngine.Net的架构模型上这种操作就失效了,我们不可以在BlogEngine.Net的数据库中修改数据而希望在它的运行系统中体现出来(除非重启应用),因为BlogEngine.Net的数据库只是完成数据存储功能,所有的业务逻辑都在BlogEngine.Core层由对象的状态维护来完成(可以参考我的第二篇文章)。有人可能会想可不可以进一步开发一种像Asp.Net中Cache那样对数据库表的依赖机制,我觉得这个问题要看需求,这种在BlogEngine.Net中似乎没有什么太多必要。
那么BlogEngine.Net的全局设置到底是怎么实现的呢?
在安装BlogEngine.Net以后进入后台管理中,我们会看到有很多分类的配置选项,包括主题,语言文化,时区等。这些配置的逻辑处理都是通过BlogEngine.Core中的一个类完成的,那就是BlogSettings。BlogSettings只是完成BlogEngine.Net的全局的配置处理,对于后文讲述的Widget的一些具体配置并不在这里完成,这主要是为了配置独立的目的,使得Widget可以独立开发。
BlogSettings与外界交互图(这个图使用画图程序弄的,大家先凑合着看吧):
在BlogSettings中除了各种配置项的对应属性以外,还有一个静态的Changed事件用来通知外部全局配置已经发生了改变,这样就可以写出更多扩展来。BlogSettings使用单例模式来实现(一个设计模式的很好的应用,全局配置具有系统唯一性)。
从这里我们就可以知道为什么对于数据源的直接修改不能在BlogEngine.Net的运行系统中体现的原因了。
BlogSettings在对象构造时执行了一个Load方法来加载所有数据存储中的配置信息,这个加载过程应用到了.Net反射技术,找到数据存储中与对象属性相同名称的配置项并将其值强制转换以后付给属性,当然这里的数据访问是通过我的第三篇文章中讲述的BlogService调用获得。同理修改配置是通过Save将数据保存回数据存储,也是使用反射完成。
客户端的使用方法(注意:这里所说的客户端是指BlogSettings使用者或调用者)
总结
从BlogEngine.Net的全局配置部分我们可以学习到以下几点:
1.单例模式是如何应用在实际项目中的。
2.配置项的数据存取部分的实现有很好的参考价值,可以了解到.Net的反射给开发带来的方便。
3.对于静态事件的使用(BlogEngine.Net中有很多例子)使得我们可以在外部做一些扩展,例如开发一个监控配置修改的跟踪系统。
好的设计要经过不断的重构才可以达到。
上一篇:BlogEngine.Net架构与源代码分析系列part3:数据存储——基于Provider模式的实现
下一篇:BlogEngine.Net架构与源代码分析系列part5:对象搜索——IPublishable与Search