Orchard 刨析：Logging
最近事情比较多，有预研的，有目前正在研发的，都是很需要时间的工作，所以导致这周只写了两篇Orchard系列的文章，这边不能保证后期会很频繁的更新该系列，但我会写完这整个系列，包括后面会把正在研发的东西跟大家一起分享（架构、思想上的分享）。
今天我们来看一看Orchard中的Logging Component。
日志在Orchard中的使用
像这样的代码大家在Orchard中肯定经常见到，那么NullLogger.Instance是什么？大量使用依赖注入的Orchard会把真正的日志记录器放在一个静态变量里面吗？答案肯定是否定的，我们来看一看NullLogger。
NullLogger明显是空的，那么ILogger到底是谁？怎么进入到服务中的？
LoggingModule
不知道大家对“Orchard 刨析：前奏曲”中的CachingModule还有没有印象，Orchard用了类似的机制，只不过这一次把构造函数注入变成了属性注入。
在Load方法我们可以看到Orchard把一个CreateLogger委托（方法）注册成为了一个ILogger接口，也就是在服务需要（请求）类型为ILogger的服务时候会执行这个委托，这个委托会返回一个ILogger实例。
我们来看一看这个神奇的CreateLogger委托。
方法比较简单，解析一个ILoggerFactory并通过LoggerFactory为请求服务的类型创建出一个Logger。
对于ILogger由谁创建的疑惑我们揭开了，但是怎么确保它是以属性输入的方式被注入进来的？下面我们接着看。
这个方法比较简单，在AttachToComponentRegistration方法中调用BuildLoggerInjectors方法生成注入的动作，并在服务被激活（服务实例创建完成后）之后执行这些委托。
BuildLoggerInjectors方法稍显复杂些，但对经常使用反射的人来说很快就能看得明白。
主要的流程如下：
1.获取服务类型中所有符合约定的属性（具有Set方法、必须是Public、是一个实例、属性类型是ILogger、不具备索引参数）
2.遍历这些属性
3.解析ILogger服务（实则调用CreateLogger）
4.把ILogger的实例设置到该属性上。
到这边ILogger是怎么被创建的我们已经明白了，那么为什么需要NullLogger.Instance呢？
为什么需要NullLogger
其实原因很简单，日志组件不一定是必要的，也就是说在框架运行起来的时候压根我们就没有日志组件，如果没有日志组件那么在解析ILogger的时候肯定是失败的（ILogger为null），这时候如果我们在服务中使用ILogger的实例肯定是未引用对象到实例，否则就需要判断ILogger是否为null在进行日志记录，岂不麻烦。所以NullLogger.Instance的用意就在解决这个问题。
ILogger是谁？
以上我们弄明白了ILogger怎么来的下面我们来看看ILogger是谁？
首先我们来看一幅图：
ILoggerFactory和ILogger这两个接口在上面我们已经知道在哪里被使用了，下面我们来看看Logging组件的具体实现部分。
不知道大家一开始看这些有没有疑惑，为什么使用了Castle Logging还要使用Log4net呢？
我们知道.net下的日志组件非常多，如：Log4net、NLog等。每一套日志组件都有部分自己特有的API，但实现的功能都大同小异，Orchard为了使API统一化而引入Castle Logging，Castle Logging并不是一个可用的日志组件，而是一套抽象的日志API。
也就是说日志的记录怎么变化只要可以适配Castle Logging就可以直接与框架集成。
CastleLoggerFactory工厂中通过Castle Logging的ILoggerFactory创建一个CastleLogger的实例。
那么具体的扩展就在Castle的ILoggerFactory中了，回顾刚才的LoggingModule：
可以发现框架默认把OrchardLog4netFactory作为了Castle的ILoggerFactory，并且上面有一行注释，大致意思是：默认使用委托果园的日志记录器到Castle的日志记录器工厂。
到这里Logging Component的整体我们都差不多了解了。OrchardLog4netFactory和OrchardLog4netLogger就不深入的，比较简单，如果阅读还是显得比较吃力可以去Log4net官网上面去看看。
OrchardFileAppender
该类并没有在编码中出现，而是Log4net提供的一种可扩展的方式，出现在log4net.config中。具体的可以去Log4net官网上了解。
写在最后
不保证很频繁的更新本系列但保证本系列肯定会写完，最近在对一个较老的组件（系统？不知道怎么命名更贴切）以新的架构新的思想和自己的方式重新编码实现，待第一版出来之后会跟大家做分享（架构、思想上的分享）。
为了本系列的读者有更好的交流环境提供QQ群一个：299744835
