感慨:当接触到微软这套程序时,代码实在是太好了,好的几乎都读不懂。好久以前就对这个套开源程序特别感兴趣,但读不明白也让人郁闷。html
可组装系统的CMS系统,OrChard在运行时能够加载modules。0.5版本的精髓就是使得组件能够随意安装,拆卸。web
Orchard像任何ASP.NET MVC工程一直,容许使用Visual Studio将模块编辑成程序集。Orchard也提供一个定制的模块加载策略,好比,它容许模块的dll无需部署在网站的bin目录下。shell
此外Orchard还能够动态的根据模块源代码来编译模块。这样能够比较灵活的部署dll文件,而且可支持在没有Visual Studio环境的状况下随时编译所修改的模块源代码。这有点相似于ASP.NET的“App_Code”文件夹,只不过Orchard支持更多的这样的文件夹。编程
Orchard的目的是为了打形成一个能够自动装载的系统架构
不是,以后每次访问数据都是从内存中获取的。 mvc
Modules | |||
Core | |||
Orchard Framework | |||
ASP.NET MVC | NHibernate | Autofac | Castle |
.NET | ASP.NET | ||
IIS or Windows Azure |
orchard framework 是Orchard项目的最低层代码。他包含该项目的引擎部分,至少说,他部分不能被隔离到Moudels层。最静态的事实是,即便最基本的模块也不得不依赖他。你能够把他看做Orchard基础类库。app
当一个Orchard web应用程序启动时,一个Host是一个单利在当前应用程序域级别。框架
下一步,Host将会获取到Shell,以便当前租户(tenant)可使用ShellContextFactory.租户(Tenants)是一个个被隔绝的应用程序(application)实例,就如用户能够被告知,可是他们运行在同一个AppDomain应用实例,以便提升站点密度。Shell是一个单利在租户级别,能够说是表明租户。它是一个能够有效地提供租户隔离的同时保证对多租户的组件编程模型无关的对象。asp.net
一旦Shell被建立,将会从ExtensionManager对象中得到到有效的扩展列表,扩展包含Modules,Themes.默认实现是经过扫描modules,themes文件目录来加载扩展。函数
同时,Shell将从ShellSettingsManager对象中获取到租户配置列表。默认实现获取配置是从适当的AppData子文件中,可是特殊的实现能够从不一样的地方获取。例如,咱们有一个Azure的实现,是使用blob来替代存储,由于在那个环境下不肯定AppData文件夹是否可写。
而后,Shell获取CompositionStrategy对象,并使用它预处理IOC容器,从(当前host的)可扩展列表和(当前租户Tenant的)配置列表。这样的结果不是一个shell的IOC容器,它是一个ShellBluePrint对象,ShellBluePrint是一个列表,包依赖,控制器和记录blueprints.
而后ShellSettings列表(针对每一个租户)和ShellBluePrint被抛进ShellContainerFactory.CreateContainer方法从而获取到一个ILifetimeScope返回对象,ILifetimeScope对象基本上使IOC容器做用返回在租户级别,进而modules(模块)能够获得当前租户做用范围内依赖注入,而不用作其余处理。
大量使用依赖注
如何将Modules块集成到系统中?
动态的加载~\Modules,还包含~\Core,~\Themes(备注:除了这三个模块不知道是否还有其余模块,但愿不要误导读者);
概述:当应用程序启动时加载进来的,在Globalx.ascx的Application_Start()函数中,调用了Starter<IOrchardHost> 的OnApplicationStart(this)时,
经过ExtensionLoaderCoordinator的SetupExtensions函数调用:
CoreExtensionLoader,DynamicExtensionLoader,PrecompiledExtensionLoader,RawExtensionLoader,ReferencedExtesionLoader,
将~\Modules,~\Core,~\Themes下资源文件信息加载到ExtensionLoadingContext对象中,并将ExtensionLoadingContext对象并在ExtensionManager的SetupExtensions函数中信息存储到内存被你持久化到xml文件中。