The model has been simply read. in depth, we may discuss how to apply Domain Modeling and related design patterns. It is not clear one or two statements. So, this time we will focus on the controller.
First, you must understand the role of controller. Without a controller, all requests are directed to the view, which makes the view bloated and difficult to maintain, such as the previous webform. Therefore, the Controller was born to remove the request processing function.
Then, the controller is basically an icontroller interface. This interface has only one method, namely: void excute (requestcontext ). This method is used by mvchandler to execute the Controller's excute method when the request arrives, so that it reaches the various action methods we compile. Here, controller can play its pivot role.
Next, it is action. In essence, action is a method that calls different actions based on different requests. Similar to pages in the webform period. In this case, it is not accurate. It is a bit similar to the page_load method. This method is automatically run when a page is requested. Well, it's a bit too much. Action can accept 0 or more parameters, which are form data, route data, and querystring. The returned value belongs to the actionresult type, which is an abstract class. If the return type is not actionresult, you can also use the MVC Architecture to automatically call the tostring () method of the return type, encapsulate it into a contentresult (derived class), and return it. He has a lot of derived classes, and he does not have much effort to list them one by one. :) In short, it is used to pass parameters to lower-layer models, generate a presentation model, and pass viewdata to the view.
Viewdata is the link connecting the controller and view. You can treat it as an idictionary <string, Object>. Of course, viewdata also has a model attribute and can be used to transmit data.
Well, let's talk about this first and talk about the feeling of a lot of things. Haha! Continue in the next day ~