I have to agree with Yi Wei’s statement. Let me add my understanding. V is verified to ensure the user experience, so that users will not find errors after submitting and go back to correct them. C is used to ensure the legality of the data itself. Verification (whether the data belongs to the user, and whether the change in data status meets the logical requirements), M transacts to ensure the existence of the data, if the data does not exist, there is no need to go below, it must be abnormal.

This question needs to be analyzed in combination with specific applications, specific languages, and specific frameworks, and is even related to the style and composition of team members.

I personally prefer M to do the verification logic, throw exceptions, and then C to capture and convert it to the format required by the front end for output. This initial code may be a bit verbose, but it is more beneficial to logical integrity and later expansion.

Another approach is to establish a so-called logic layer between M and C to handle verification logic and part of the business logic

Generally, in the MVC framework, a service layer will be added based on business processing. The model will be ORM mapped or discarded directly and write a DAO. Okay, now let’s talk about which layer the verification is done in. The most correct method is the controller. Both layer C and service layer S must be done, because as the website develops, it is definitely necessary to separate the service as a public service component for remote calling, so if you do not do verification at the controller layer, there will be For data requests, you directly send them to public services. If there is a problem with the data, and then return an error, this will obviously waste a network IO. So if you have done data verification at the controller level, when the data is incorrect , throw an exception directly, no need to make a remote call through RPC

This definitely depends on the situation:

• The legality of the text format: Just use js verification or regular expressions to handle it on the front end.
• Data validity issue:
  
  
  • Simple case: For example, verifying the legality of the year, month and day can also be done on the front end.
  • Broader situations: including the above two situations, as well as user name verification, repeatability verification, etc., situations involving specific business logic, represented by the Rails framework, are placed in the Model to complete the verification.

Fat model, skinny controller.

Echang coding has a principle: interfaces do not trust each other.

If you write it yourself without any framework, it should belong to the c layer. But more frameworks tend to be placed in the m layer.

In addition, don’t only perform input verification on the v layer. The front-end stuff can easily be bypassed, which poses security risks.

Each layer must be done with different emphasis.

We usually add a Service layer between C-M of MVC (but it can also be understood as part of C or M). This layer is designed to be decoupled from View and Controller, and can be independently stripped out to the outside. Called (API).

So,
In the View, perform a relatively weak legality check of a single value,
In the Controller, verify the legality of external request packets and verify some user interface permissions;
Perform strict data legality verification, business logic constraint verification, and user data permission verification in Service;
Perform physical legality verification of data in the Model.

If the subject has used frameworks such as Python's Django or Flask, you will find that there is also a Form class. The logic of user content verification is generally done in the Form class. Because sometimes, we may need to make different validation rules for the same Data model according to different situations. Of course, Django also supports model layer verification. Relatively speaking. The Form layer does this with a lower degree of coupling.

Simple MVC usually does FORM verification on the model layer, while more mature solutions usually separate FORM. Take joomla as an example, it has a FORM layer and is integrated into the model layer. Structurally, it belongs to the model layer. But the implementation of the function seems to have nothing to do with the model layer.

In fact, the legality check is also divided into local and server side.
For example, if the input is empty, it is checked on the V layer; if the input format is incorrect, it is checked on the M layer.
If you want to further check whether it is qualified, you can put it on the M layer and check it by accessing the server.