. Net mvc and three-tier architecture,. netmvc three-tier architecture

. Net mvc and three-tier architecture,. netmvc three-tier architecture

Although they have been in contact with the two for a while, they may still be confused. Here, we do not intend to explain the difference between the two because they are both architecture models and have a certain degree of coexistence, in actual development, strict differentiation is of little significance. Based on the recent introduction to this part of knowledge, the basic concepts are more important than technologies in programming.

Let's take a look at the three-tier architecture, namely the UI (presentation layer), BLL (business logic layer), and DAL (data access layer ):

UI (presentation layer): mainly refersAndUser interaction interface. It is used to receive user input data and display the data that the user needs after processing.

BLL: (business logic layer): a bridge between the UI Layer and the DAL layer. Implement business logic. The business logic includes verification, calculation, and business rules.

DAL: (data access layer): Dealing with databases. It mainly adds, deletes, modifies, and queries data. Submit the data stored in the database to the business layer, and save the data processed by the business layer to the database. (Of course, these operations are based on the UI Layer. User requirements are reflected on the interface (UI), and the UI is reflected on BLL, BLL is reflected on the DAL, DAL is used to perform data operations, and then return one by one after another, until the user's required data is fed back to the user)

In fact, all those who have actually used a three-tier architecture know that they transmit data through Entity. Entity runs through three layers, connects the three, and encapsulates data entities, instead of multi-variable data transmission (Data Exchange) between layers, this greatly simplifies data exchange and reduces the probability of data errors. (Entity is actually the encapsulation of database table entities), the dependency between Entity and Layer 3:

　　　　

 

Let's look at the MVC Architecture, namely, M (model ·), V (view), and C (controller. These three parts are necessary in the MVC Architecture, but we can also add them based on the actual needs and actual conditions of the project, such as implementing the Service layer or Repository layer, we can expand on our own, greatly improving the flexibility during development.

Model (Data Model): it is used to encapsulate data related to the business logic of the application and the processing method for its data operations (database access operations, that is, adding, deleting, modifying, and querying; definition of data structures; validation of data formats ). The Model does not depend on View and Controller. That is to say, the Model does not need to know how it will be displayed or applied. You only need to focus on your responsibilities. Common technologies in Model include Entity Framework (EF), nhib.pdf, LINQ to SQL, Typed DataSet, and ADO. NET.

View, however, a View does not depend on a Controller. Any Controller can display the data required by a View based on the display logic, which is a loose relationship.

Controller: belongs to the role of a result coordinator, because the three parts of the M-V-C are not directly linked, View can not directly communicate with the Model, that is, the Model can operate the data, view can display data. Therefore, the data displayed by the VIew must be obtained by the Controller from the Model and provided to the View. That is, the Controller role is located in the middle of the user interface layer and the business logic layer.

 

Among them, the most important feature of MVC is the separation of concerns and the Convention is better than the configuration. Separation of focus, simply put, is "only pay attention to what needs to be paid attention to". In this way, modules can be well decoupled, and the complexity of each unit is reduced, making it easier to develop. At the same time, it also enhances the maintainability of the program. Conventions are better than configurations. Simply put, they are the conventions that should be observed during the development process. For example, the name of the Controller file must end with the Controller; the View file must be placed in the VIews folder; the View name is the Action name of the corresponding Controller; the HTTP verb should be added before the Action name of the Web API, which is conducive to the later development and maintenance of the project, to prevent the project from being willing to take over due to the movement of people.