Structure Analysis of oxite Analysis

Change set: 46759
Download: http://oxite.codeplex.com/SourceControl/ListDownloadableCommits.aspx

Conventions:
1. To eliminate ambiguity, the entire oxite project is collectively referred to here as the oxite solution, and an oxite project is under the oxite solution.
2. A module is called a module.

1. Analysis of oxite solution structure from the perspective of modules

The oxite solution can be viewed as a collection of modules in a certain way.
The oxitesite Project is a siteProgramProject. The oxite solution is an application of ASP. net MVC mode solution, while the oxitesite project is equivalent to the view in MVC (while the model and controller are distributed in each module, see (2 )).
The oxite project provides some infrastructure to support hot swapping of modules and has some built-in modules (which modules are detailed here ).
The modules solution directory contains some extension modules, such as oxite. Blog and oxite. CMS.

Figure 1 shows the structure of the oxite solution from the "module perspective.

(Figure 1: oxite solution diagram, with arrows indicating inclusion relationships)

The aspnetcache, core, and other modules are presented to demonstrate that these modules under the oxite project are in a relatively equal position with each project module under the modules solution directory. The difference is that aspnetcache, core, and other modules are at the core, so they are "built in" in the oxite project. If necessary, you can separate these modules into projects similar to oxite. blogs. Although these core modules are built in, oxite allows replacement of these modules.

Ii. Analysis of oxite solution structure from the perspective of ASP. NET MVC

Oxite was originally designed as a project to learn ASP. net mvc, which is also an important reason for our analysis and learning.
From the file structure of the oxite solution, we can easily see that the oxitesite project should be the view part of MVC. What about model and controller?
In oxite, model and controller are located (or scattered) in each module.

Figure 2 shows the structure of the oxite solution from the MVC perspective.

(Figure 2: oxite solution structure, with arrows representing dependencies)

 

 

Cntroller obtains model data through iservice (configured in dependency injection mode;
The model data and the linqtosql model use irespository (configured in the form of dependency injection) for access and conversion.
The controller does not have any dependency on the database and data access methods. This means that different repository methods can be used to obtain different data access methods or databases.

The Controller and model data are divided into different modules. For a specific module, such as the core module, the model corresponds to the site entity; the Controller corresponds to sitecontroller (other controllers won't be mentioned here); The iservice corresponds to isiteservice, the specific class is siteservice; The irepository corresponds to isiterepository, and the specific class is sqlserverrepository.

There are two other points to be declared:
1. If any of the identifiers and symbols used in the structure chart are inappropriate, I still want to correct them because I have not drawn any picture, it is drawn in Word.
2. Here the model is understood as an entity and ASP.. Net MVC. The model and service (that is, the business logic layer) Here are merged into M of ASP. net mvc. I hope you can give me more advice.