I have read some ideas about ASP. NET MVC open-source projects and some ideas about ASP. NET MVC + repository + service architecture.

I recently learned some open-source projects of ASP. NET MVC 2.0 and found that the same architecture design is widely used in these projects, namely:

ASP. net mvc + Service + repository. After reading some introductions on the internet, I think this architecture is indeed full. Take Microsoft's typical open-source project oxite as an example:

This project is composed of the following projects:

1) oxite;

2) oxite. linqtosqldataprovider;

3) oxite. MVC;

4) oxite. MVC. tests;

5) oxitesite;

 

Oxite project:

1) define the model to be used in all projects, that is, entity, and all models are pure models, which do not depend on any information related to the ORM framework. Model is used to transmit data between the UI Layer, business logic layer, and data access layer;

2) define the repository interface. Repository is similar to the database access layer (DAL) in a three-tier architecture in terms of form and function. I personally think the difference between the two is different from that on the diagram.
Repository is a concept in DDD (domain-driven design domain-driven model). It is emphasized that repository is driven by domain. The features defined in repository must reflect domain intent and constraints, the more pure dal is to provide data access functions, not strictly limited by the business layer. All interfaces provided by repository should be required by the business logic layer. If the business logic is not required, it does not need to be provided. However, I recently saw some friends on the Internet implementing some generic repository interfaces, which I think is not very good. This violates the original intention of designing repository. The repository interface is an operation contract provided to the domain layer. Different entity may have different operation constraints for the domain, for example, the user may not be deleted, and the bookorder may not be modified. That is to say, the domain layer should not be able to call _ repository <user>. delete (user), _ repository <bookorder>. update (bookorder. Therefore, the repository interface should be defined separately for each entity class.

3) define and implement the service layer.

The servide layer defines and implements the entire application.ProgramAll business logic. Service uses the repository interface to perform database operations. In addition to using repository to operate databases, each service interface also performs many additional tasks, such as data verification.

 

Oxite. linqtosqldataprovider project:

This project is a specific dataprovider (repository) implemented by using the LINQ to SQL ORM technology ). This project will define some entities related to the LINQ to SQL ORM framework. With the powerful syntax function of LINQ, we can easily convert these entities to the entity defined in oxite. For example:

1 Public User getuser ( String Name)
2 {
3 Return (From u In Context. oxite_users
4 Where   String . Compare (U. username, name, True ) =   0
5 Select New User ()
6 {
7 ID = U. userid,
8 Name = U. username,
9 Displayname = U. displayname,
10 Email = U. email,
11 Hashedemail = U. hashedemail,
12 Password = U. Password,
13 Passwordsalt = U. passwordsalt,
14 Status = U. Status
15 }). Firstordefault ();
16 }

 

 

Oxite_user is the entity generated by the LINQ to SQL ORM framework, and the user is the entity defined in the oxite model.

 

Oxite. MVC project:

This project contains all controllers, but does not contain views. The Controller is responsible for using the service layer to provide services for views. Generally, any technology related to ASP. net mvc should not be implemented in the service layer, but in the controller. This ensures that the service layer can be reused by non-Asp. Net MVC programs.

 

Oxitesite project:

This project is a common ASP. net mvc website, but it only contains some views, JS and CSS.

 

Summary:

I think the above architecture design has the following three benefits:

1) The oxite project actually fully represents the application. Because an application consists of three parts: Ui, business, and data. This project contains business and data. Of course, it should be said that it contains a description of the business logic of the entire application, and does not contain specific business logic implementation, data Persistence of specific business logic is implemented through oxite. linqtosqldataprovider is implemented in this project. However, this does not affect our understanding of oxite as the main body of the application. So I think this project is the model in the ASP. NET MVC Architecture.

2) The repository mode is used to completely separate the application's business logic from the data persistence work. Therefore, we can write many different ORM frameworks to complete data persistence. The only thing we need to configure is in the web. in the config file, set which dataprovider to use. Of course, for the open-source project oxite. linqtosqldataprovider separately defines another set of entity, so that we must convert an entity when querying data. This may be a bit bad for me. Of course, in fact, LINQ to SQL supports XML to configure the ORM ing relationship. Therefore, in theory, we should support not defining another set of entity.

3) the foreground is implemented using ASP. net mvc technology, and the Controller and view are separated in different projects. I personally think the main consideration is for better team development. Let the developers focus on the design view, and let the Controller developers focus on the control and coordination between the view and model.

 

Therefore, we can imagine that if an application is developed based on this architecture, I think we can first develop a model and then develop one or more dataprovider to implement the business defined in the model, then, you can write a test project to test the model. After the model is stable, you can develop view and controller.

 

The above is a little bit of my thoughts on some ASP. net mvc open-source projects recently. You are welcome to criticize and correct them.