Orchard源码分析（1）：插件式的支持——模块和主题

在Orchard，模块和主题都是可以插拔式的，在源码处理时，用类型(参考：DefaultExtensionTypes)区分，都没太大的本质区别，以下都称做模块。

插件的支持，实现分以下几步：

搜集模块的信息

确定模块的加载器

复制DLL到App_Data\Dependencies文件夹（动态编译的项目不复制）

加载启用模块的程序集，如果是动态编译项目，开始编译

得到程序集的里所有公共的类（不包含IsAbstract）

加载类型到autofac容器中，构造网站运行环境

搜集模块信息

Orchard目前支持三个目录去搜索模块：Core，Modules，Themes。模块都是存放这几个文件夹下的子文件夹，并且包含Module.txt文件（Core，Modules文件夹下）或Theme.txt文件（Themes下）。

这个搜集外部调用，是接口IExtensionManager函数

IEnumerable<ExtensionDescriptor> AvailableExtensions();

来实现的。通过接口（IExtensionFolders）的所有实现类来查找。这个过程里，使用了大量Cache(ICacheManager)。

接口（IExtensionFolders）的实现类：

CoreModuleFolders：处理Core目录

ModuleFolders：处理Modules目录

ThemeFolders：处理Themes目录

这些类负责传入要处理的文件夹，处理类型，具体的处理工作由接口（IExtensionHarvester）的实现类（ExtensionHarvester）来完成。以Modules目录为例，该类首先找出Modules下的子目录，循环分析子目录下的Module.txt文件，分析文件后，得到一组ExtensionDescriptor对象。ExtensionDescriptor对象，就是以后处理过程的基础。

确定模块的加载器

Orchard里面有很多的模块，支持的模块加载方式也多样。如Core目录下的模块，代码都放在Orchard.Core.dll中的。Modules目录下的模块，可以支持动态编译，也可以支持加载dll。负责加载模块dll的，就是实现接口（IExtensionLoader）的类。

类名	Order	优先级	说明
CoreExtensionLoader	10	100	处理Core目录下的模块,直接加载Orchard.Core.dll程序集
DynamicExtensionLoader	100	0	如果模块目录下存在文件(模块名.csproj)，这个加载器就做为一个备选
PrecompiledExtensionLoader	30	0	如果模块目录下的bin目录存在文件(模块名.dll)，这个加载器就做为一个备选
RawThemeExtensionLoader	10	0	处理Themes目录下主题，并且这个主题目录下，不能包含（主题名.csproj）文件和bin目录下，不能包含（主题名.dll）文件。
ReferencedExtensionLoader	20	100	如果模块的程序集已经加载到程序域中，并且在web的bin目录下，存在文件（模块名.dll）这个加载器就做为这个模块的备选项了。这种情况，一般是web项目，直接引用了模块项目。

CoreExtensionLoader

这个加载器只处理Core目录下的，加载程序集时，就加载Orchard.Core.dll，很大程度已经加载到程序域了。也没有其他的备选加载器了。处理相当简单

DynamicExtensionLoader & PrecompiledExtensionLoader

这两个加载器，是Modules目录下的模块经常可备选的。我们在开发自己模块时，当我们编译代码后，就生成了文件ModuleName.dll。这个时候，这两种加载器都满足了条件，做为了备选项。这两种加载器，具体使用哪个呢？

使用优先级最高的

两个优先级一样时，按依赖项的修改时间，使用依赖项最近修改的。DynamicExtensionLoader 的依赖项是项目文件及其源码，如果还引用了其他项目，那个项目的依赖项，也就包含在内了。PrecompiledExtensionLoader依赖项就是ModuleName.dll文件。 项目的依赖dll是要除去已经加载到程序域的程序集

依赖项修改时间一样时，使用Order值小的

RawThemeExtensionLoader

这个加就是用来加载不包含项目文件的主题，没有太多的处理

ReferencedExtensionLoader

从表的说明看出，这个加载器，是加载放置在~/bin目录下的模块代码的。为了效率，可以禁用一些加载器，那也就可以把模块代码放置到~/bin目录下了。

复制DLL到App_Data\Dependencies文件夹

确定了模块的加载器后，就需要把一些程序集复制到App_Data\Dependencies目录。从以上的分析可以看出，只有加载器DynamicExtensionLoader 和PrecompiledExtensionLoader需要复制程序集。PrecompiledExtensionLoader需要复制模块dll和依赖项dll。DynamicExtensionLoader 只需要复制依赖项dll就可以了。。经过这一步后，模块的dll及依赖dll，都复制到了Dependencies文件夹。为什么要复制到Dependencies呢？在Orchard.Web项目的web.config的配置节：

runtime>assemblyBinding>probing[privatePath]设置了App_Data/Dependencies。关于这个配置，参考http://msdn.microsoft.com/zh-cn/library/823z9h8w(v=vs.85).aspx。指定加载程序集时公共语言运行库要搜索的应用程序基子目录。就是增加了个类似~/bin目录的程序集搜索目录。

复制完DLL后，会根据可用的模块，模块使用的加载器，在App_Data\Dependencies目录保存两个文件：dependencies.xml和dependencies.compiled.xml文件。这样就保存了处理的结果，不然就白忙活了。

dependencies.xml：文件保存模块名，模块目录，加载器名，以及依赖项

dependencies.compiled.xml：保存模块的名称，模块目录，加载器名，还有就是模块的Hash值。这个Hash值是通过模块的名称，依赖项，修改时间生成的。

加载启用模块的程序集，如果是动态编译项目，开始编译

模块的信息及DLL都准备好了，下面就是按需加载了。具体加载哪些DLL，是看启用了哪些Feature。启用的Feature保存在文件App_Data目录下的cache.dat文件，它是一个XML文件。这个文件保存多个网站（Shell）启用的Feature。通过模块描述文件（Module.txt），可以知道模块提供了哪些Feature。启用的Feature一对比，就找到了模块名称了。

每个模块使用哪个加载器，在上一步已经确定了。通过对比加载器的名称，找到加载器，调用加载器的函数：

ExtensionEntry LoadWorker(ExtensionDescriptor descriptor);

CoreExtensionLoader：直接加载Orchard.Core.dll

PrecompiledExtensionLoader：加载模块的程序集

ReferencedExtensionLoader：加载~/bin目录下的模块程序集，如果不存在，就返回null

RawThemeExtensionLoader：不加载程序集

DynamicExtensionLoader：下面形式调用，动态编译程序集。动态编译程序集在此不深入，打算写另一篇文章说明。

BuildManager.GetCompiledAssembly("~/Modules/ModuleName/ModuleName.csproj");

得到程序集的里所有公共的类

得到程序集后，就会返类型ExtensionEntry

return new ExtensionEntry {
Descriptor = descriptor,
Assembly = assembly,
ExportedTypes = assembly.GetExportedTypes()
};

得到这个对象后，遍历ExtensionEntry.ExportedTypes，根据类型是否有OrchardFeatureAttribute属性，确定类型所属的Feature。最终到的一组Feature类型

public class Feature {
public FeatureDescriptor Descriptor { get; set; }
public IEnumerable<Type> ExportedTypes { get; set; }
}

所有的Feature得到后，首先排除类型中有标注OrchardSuppressDependencyAttribute属性的。这个标注，是为了去掉指定的类型。从类型集中，要得到5种类型：

IModule对象：实现接口IModule的类型

IDependency对象：实现接口IDependency的类型

IController对象：实现接口IController的类型

IHttpController对象：实现接口IHttpController的类型

Record：1)类型的命名空间以（.Models）或者（.Records）结尾。2）有名称为（Id）的属性，并且是Virtual的。 3）类型不是密封（Sealed） 4）类型不是虚类型（Abstract）5）类型没有实现接口（IContent），如果实现了该接口，但是从ContentPartRecord类型继承的，也可以。

这样就准备好了要加载到autofac容器中的类型。

加载类型到autofac容器中，构造网站运行环境

加载类型到autoface容器，由接口IShellContainerFactory的实现类ShellContainerFactory来处理。

首先从ShellBlueprint.Dependencies集合中找出实现IModule接口的类型，注册到中间容器中。

从中间容器中得到IModule类型，调用RegisterModule注册。

从ShellBlueprint.Dependencies注册类型，并根据实现的接口IDependency类型，设置生命周期

ISingletonDependency：在一个shell中是单实例的

IUnitOfWorkDependency：在一个work是单实例的

ITransientDependency：每次请求都是新的实例

特别注册实现接口IEventHandler的类型，使用接口的名称，命名注册的类型

注册IHttpController类型，添加一个名称为ControllerType，值为类型对象的Metadata，供其他模块使用。

调用IShellContainerRegistrations接口的实现类，使用代码来向容器中注册类型。默认实现什么都不做，可以自己实现这个接口。

从文件注册：支持从两个文件加载 1）~/Config/Sites.config 2）~/Config/Sites.{SiteName}.config 这提供了站点可多样的注册。

最终得到网站的运行环境类型：

public class ShellContext {
public ShellSettings Settings { get; set; }
public ShellDescriptor Descriptor { get; set; }
public ShellBlueprint Blueprint { get; set; }
public ILifetimeScope LifetimeScope { get; set; }
public IOrchardShell Shell { get; set; }
}

属性说明：

Setting：网站的配置值，从App_Data\Sites\{SiteName}\Settings.txt读取

Descriptor：网站启用的Feature。

Blueprint：包含网站关心的类型

LifetimeScope：网站独立的容器对象，这样不同的网站对象，就不会影响了

Shell：可以启动和终止一个网站。