Controller-controller view (3)

All requests filtered by URL routing are mapped to a specific controller and processed by the methods specified by this controller. Therefore, the controller is the place where developers write code to process requests. Now, let's take a brief look at all aspects of the controller.

Controller Granularity

An ASP. net mvc application usually consists of several controller classes. But how many controllers do we need? The specific quantity depends on how you organize the behaviors in applications. In fact, you can also set a controller in your application and put all the requests processed in this controller.

One of the most common practices is to create a controller for each of the important functions in your application. For example, you can createCustomercontrollerClass to process query, delete, update, and add user requests. You can also createProductcontrollerTo process product-related requests. Most of the time, these controller objects are directly associated with projects in the main menu of the application.

Generally, we can think that the granularity of the controller is the granularity of a user interface function.

Stateless component

The program instantiates a new controller object for each request. All possible states you add to the controller are bound to the request lifecycle. To make the controller work properly, he must be able to obtain relevant data from the HTTP request stream and HTTP context.

You decide the future hierarchy.

Often, ASP. net mvc and controller classes are amazing, so you want to layer them to make the application look clean and improve readability and maintainability. In this regard, the stateless feature of the controller is of great help, but this is not enough.

In ASP. net mvc, the controller is separated from the user interface that triggers the request and the engine that creates the view. The Controller is in front of the view and background system. Although this separation is good from the perspective of views, it solves the shortcomings of ASP. NET web forms. However, this does not guarantee that your code has reached the principle of separation of focus.

You can remember that nothing, even in ASP. net mvc, can prevent you from directly using ADO. net in the Controller to call T-SQL statements. The Controller is neither a background system nor a business logic layer. On the contrary, it should be considered as a copy of the hidden code class of web forms. Therefore, in terms of concept, it should belong to the presentation layer rather than the business logic layer.

High Testability

The inherent stateless nature of the Controller and Its perfect separation from the view make the Controller class very easy to test. However, the true testability of the Controller should also evaluate its effective layering.

Although you can pass in any input you specify to the Controller, and its output will not be a big problem, the internal structure of the behavior method cannot be guaranteed. The deeper the implementation of behavior methods is associated with external resources (such as databases, services, and components), the more difficult the testability of controllers.

Controller-controller view (3)