I want to understand what is the main difference in these two diagrams when it comes to the Model-View-Controller pattern. If there is a difference, how should I choose to construct my program? What conditions should make me choose the first design (or the second)?
But I am not even entirely sure if they are different, they could be meaning the same thing at the end of the day. I hope someone can explain, thank you
There are many different flavours of the "MVC" architecture, and the diagrams represent two such flavours. I will call the two main flavors "GUI-MVC" and "Web-MVC".
MVC originated in the context of 80s-era Smalltalk GUI applications. The seminal paper on this pattern is A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80 by Krasner and Pope (1988). At the time of writing, a PDF is available here. They show the following diagram for the MVC architecture:
In modern terms, the model contains business logic but also represents current state, the view displays the model state via data-binding, and the controller contains event handlers for user input.
Your first diagram summarizes the main data flow in this traditional GUI-MVC architecture. It is generally similar to the diagram by Krasner & Pope, but introduces the user as an explicit part of the system, and elides additional communication paths (such as Model→Controller notifications, Controller→View updates, and View→Model access).
In a web context, the term "MVC" is used to describe a notably different architecture. Back when Web-MVC was popularized, there was no real-time connection between frontends and backends (like we have now with WebSockets). There were only HTTP requests.
So the GUI-MVC best practices were re-cast into the terms of server–client communication. The model contains business logic and persistent data. The view is the HTML (or other representation) that is displayed to users. The controller is the component that handles HTTP requests on the backend and translates it into model operations, such as updating databases. Sometimes, applications are already claimed to follow the MVC architecture if the web backend uses a template engine (for views) and an ORM (for the model), an interpretation that is quite unlike GUI-MVC.
Your second diagram summarizes the dataflows in this Web-MVC flavour of the architecture.
There is a crucial difference especially in the role of the controller between these architectures.
In GUI-MVC, the view uses a controller to handle events. For example, the view might invoke the controller's methods to handle a mouse click or a keyboard shortcut. The controller then invokes suitable methods in the model. Through databinding/observers/pubsub, the view is notified of updates in the model and shows the new state.
In Web-MVC, the controller mediates all interaction with the model. Similar to GUI-MVC, the controller invokes model operations. But then in an inversion of the GUI-MVC data flow, the Web-MVC controller loads relevant data from the model, constructs a new view (e.g. by rendering a HTML template), and returns it to the client. There is no direct Model–View communication, and in practice the controller starts to take on responsibilities from the view and model as well (especially in CRUD applications).
Subsequently, many more architectures have been developed, for example:
None of this is particularly helpful when creating new architectures now. It is likely that you're using some GUI framework. This GUI framework will likely impose a certain architecture or data flow. For example, in web frontend development, frameworks like React or Vue offer databinding, which pushes you strongly towards a GUI-MVC like views, but doesn't necessarily enforce a controller vs model separation. I recommend following the application design guides offered in your framework's documentation.
These diagrams are both too vague to reason about in any detail.
For example, let's try to make statements from the diagrammed connections between components, for the first diagram we could say:
The User "Uses" the Controller; The Controller "Manipulates" the Model; The Model "Updates" the View; The View "Sees" the User.
This last one makes little sense, why would the Views See the User? (Because they want to make the diagram into a complete circle. Probably "Presents to" would make more sense for the arrow label.)
In the second diagram, according to the labeled arrows, the Controller requests data of the Model, but has no called-out capability to request changes to the Model — this is obviously an omission.
I point these out to show that these are abstract, and it is unclear as to what their focus is and what is purposefully being omitted, so they are hard to take seriously especially in direct comparison with each other. Further, one is about some kind of high level interaction between components (Manipulates, Updates, that are not broken down into directional messaging), and the other about request- and reply-type messaging between components that accomplish (unstated) higher level interactions.
Still, following the diagrams, the latter gives the Controller a more central role in that it interacts with all the other components, which seems more realistic to me.
MVC systems should allow multiple views; usually the Controller requests new Views to be created, but in this first diagram, apparently communication between Controller and View goes through the Model. This can make sense in some contexts, if some Views are actually a formal part of the Model, but some Views or variants on them are private to the User or their session, which requires extra Model communication.
They use different colours, attempting to be funny.
Beyond the appearance they model two possible implementations of command line interface (CLI) applications, considering the user - controller direct communication. In one diagram the controller being intermediary for the user, is the orchestrator, it receives requests from the user and coordinates the processing, while in the other one the user is the orchestrator, sending requests to the controller that dispatches them for processing.
Both representations have something in common they both inaccurately depict the MVC pattern. With MVC implementations the view is the system boundary, consequently the direct communication is between the user and the view, where the view lists available options to the user and sends requests to the controller based on user generated events.
