Oxite分析之结构浅析

change set:46759
download:http://oxite.codeplex.com/SourceControl/ListDownloadableCommits.aspx

约定：
1、为了消除歧义，整个Oxite项目在这里统称为Oxite解决方案；而Oxite解决方案下有一个Oxite项目。
2、Module称之为模块

一、从模块的角度浅析Oxite解决方案结构

Oxite解决方案从某种角度上可以看成是一系列模块(Module)的集合。
OxiteSite项目是一个站点程序项目。Oxite解决方案是一个应用了ASP.NET MVC 模式的解决方案，而OxiteSite项目就相当于MVC中的View（而Model和Controller则分布于各个模块中，详见（二））。
Oxite项目中提供了一些基础架构用于支持模块的热插拔，而且内置了一些模块（具体是哪些模块，这里不详解）。
Modules解决方案目录下是一些扩展模块,如，Oxite.Blog,Oxite.CMS等等。

图1从“模块的角度”大致表现Oxite解决方案的结构。

（图1：Oxite解决方案结构图，箭头表示包含关系） 

 

上图将AspNetCache、Core等模块表现出来，是为了说明Oxite项目下的这些模块，与Modules解决方案目录下的各个项目模块处于相对平等的位置。区别在于AspNetCache、Core等模块比较核心，就将其“内置”于Oxite项目中而已。如果需要，可以将这些模块独立成类似于Oxite.Blogs等的项目。需要说明的是，这些核心的模块虽然内置实现了，Oxite也允许对这些模块进行替换的。

二、从ASP.NET MVC的角度浅析Oxite解决方案结构

Oxite最初设计成为学习ASP.NET MVC的项目，这也是我们进行分析和学习的一部分重要的原因。
从Oxite解决方案的文件结构上看，我们很容易看出OxiteSite项目应该就是MVC的View部分。而Model和Controller部分呢？
Oxite中，Model和Controller位于（或者说分散于）各个模块之中。
 
图2从“MVC的角度”大致表现Oxite解决方案的结构。

（图2：Oxite解决方案结构图，箭头表示依赖关系） 

 

 

Cntroller通过IService(以依赖注入的方式配置)获取Model数据;
Model数据与LinqToSql的Model通过IRespository(以依赖注入的方式配置)进行存取转换。
Controller对数据库和数据访问方式是没有任何依赖的，这就意味着实现不同的Repository就可以达到获取不同的数据访问方式或数据库。

Controller和Model数据和分于不同的模块之中。具体的某一模块，如Core模块，Model对应的是Site实体；Controller对应SiteController(还有其他Controller这里就不说了)；IService对应的是ISiteService，具体类为SiteService；IRepository对应的是ISiteRepository，具体类为SqlServerRepository。

另外还有两点需要声明的是：
1、结构图中所用标识、符号如有不恰当还望指正，因为我没怎么画过图，以上图是用Word画出的；
2、Model在这里的理解是实体，并理解为ASP.NET MVC中的M。有关资料将这里的Model和Service（即业务逻辑层）合并理解为ASP.NET MVC的M，希望明白的朋友多指教。