---

the subject understands it well. It is common to think that this is the mode of MVC:

1. user triggers at layer v
2. then request layer c
3. c layer calls m layer to get data
4. layer c reintegrate data
5. finally, c layer calls v layer display

the MVC design pattern above should be the original MVC design pattern. Later, with the diversification of programming and design patterns, many derivative versions have been added on this basis (M model C controller V view).

As far as I understand, MVC is a noun, or a code name, a design pattern. However, how the three should be related and what kind of connection they produce is not determined by the stipulation, but depends on the actual business architecture.

---

first of all, MVC was born in 1979. It can be said that computers at that time were completely different from those of today. At that time, there was no graphical interface, and the computer program was very "rigid", requiring the operator to enter instructions (usually a keyboard and a card reader), calculate according to the prescribed algorithm, and return the results. So the controller, of that period was responsible for receiving user instructions, reading and writing data, and calling view display, that is, your understanding of the subject, which was actually correct.

almost all the explanations you can find on the Internet about the difference between MVC and MVP are forced by the author with "my understanding", and they are all wrong. Without exception, its authors all ignored the development of computers and graphical interfaces, bringing in current smart devices and virtual components (such as buttons) to explain how MVC, thought View could accept user actions, pass instructions to controller, and then what. So it seems that there are all kinds of logical inconsistencies.

this is the only correct explanation I know:

c change m, m causes v to update, v operation c changes m

---

view and model do not interact.

digression: now we basically use Controller < = > Service < = > Model, to add a service layer, but I am free to use service layer. The view layer is also completely independent as the front end

---

what does mvc, say? It's quite abstract to say. In general, in order to make the hierarchical structure clearer, the role of each layer will be clearly defined.

controller mainly forwards requests. The model layer mainly deals with business logic, and sometimes it depends on the complexity of the business. If the business is quite simple, model is obviously a bit redundant, and some people in model will directly perform use in view for rendering processing. Mvc itself is also based on software changes, and the summed up experience is also for better collaborative development by the team, adapting to complex businesses, and so on. Specifically, it depends on the complexity of the company's business. Individuals feel that the direct interaction between the model layer and view is inappropriate. First, it is not conducive to the separation of the front and rear ends, and second, the readability of the code is reduced. Now it is better for the back end to provide api interface front-end processing interface. So. There is no absolute mvc, only a mvc suitable for business change.

---

YII is to use M to operate V, especially when using its widgets, the logic is all in M

---

, as long as the mvc is separated from each other, it is the art of software design

---

after reading the above answers, they are all wonderful. I would like to talk about some of my personal understandings and thoughts.

C layer, from the point of view of the function of the program, it is mainly used to receive the data request from the client, and then return the request from the client, and deal with the things that belong to the same business independently through the methods in the C layer.

M layer, in fact, this layer is mainly the processing of data logic, and the main function is actually responsible for the operation of the database. At the database level, split our usual data structures into one table or multiple tables and store them in the form of two-dimensional tables. Then this M layer is usually responsible for adding, deleting, changing and checking these basic operations. But generally speaking, we also do some logical operations here.

V layer, relative to the back end, is the view layer, that is, what it will eventually look like, but this V layer is usually something similar to a template, and then the C layer calls the M layer to get the result, and then throws it to a renderer. The renderer calls the V layer template to fill in the result data returned by M to get a specific result.

so generally speaking, the V layer basically has no specific processing logic for the data, at most some for traverses the list, and then displays the data once, and adds some if conditional judgment at most. But in fact, in the process of use, it is impossible for everyone to follow this line of thinking, it may be directly in the View layer to call the model layer to write the query, there may be other logical calls, so the significance of the View layer is actually not great.

generally speaking, MVC programs have to go through such a process no matter what they do, but in fact, modern web has a lot of asynchronous interactions, while in the process of asynchronous interactions, there are only C layers and M layers, because it does not involve back-end data rendering. And now a variety of webAPP or single-page development methods, restful interface design, etc., the back end may only have a C layer and model layer. In this case, the C layer is usually independent of the business logic, while the M layer is the program of the details involved in the specific business logic.

in addition, as development ideas evolve, the basic design may usually look like a C layer and an M layer, but in fact, there may be a data verification layer that specializes in data validation, exception handling, and define various ways of throwing exceptions, and so on, and maybe even cross-server communication layers. In this case, the M layer may really be just a function of adding, deleting, changing and querying data, and the corresponding C layer is only a semantic encapsulation of business logic in the outer layer, and its own specific implementation may be based on different businesses. the way of writing should be understood according to the design pattern.

in fact, I personally think that it may not be of much significance to struggle with this. The key point is to have a certain uniform standard in planning the program without losing the maintainability and expansibility of the program. Of course, I think the most important thing is to add notes.