Since there was no answer, I decided to publish it. It is largely based on
Architecture Model-View-Controller (MVC) ( WEB ) ( PDF ). Indicated by: Tom Ingram (thanks).
Article:
John Deacon is a lecturer and writer. Object Oriented Analysis and Design: A Pragmatic Approach. (for more information about the author, see the About the author section here )
Now the diagram most suitable for MVC architecture:

Three parts:
Model -View Controller:
We will call the immutable essence of the application / domain, the model (in the singular). In object-oriented terms, this will consist of a set of classes that model and support the underlying problem, and therefore will tend to be stable and durable as the problem itself.
How much should the model (classes) know about communication with the outside world? Nothing, absolutely nothing.
Model- View -Controller:
For this situation, this version will have one or more interfaces with the model, which we will call representations (plural). In object-oriented terms, they consist of sets of classes that give us “windows” (very often actual windows) on the model, for example.
- View graphical user interface (GUI / widget) (graphical user interface),
- Command Line Interface (CLI) mapping
- API interface (application program interface).
Or:
- Introducing Newbies,
- Expert opinion.
Although representations are very often graphic, they do not have to be.
What are the ideas about the model? They need to know about its existence. They need to know something about their nature. For example, the bookingDate input bookingDate may display and possibly change the instance variable of some model class.
Model-View- Controller :
A controller is an object that allows you to manipulate viewing. By simplifying the bit, the controller processes the input, while the view processes the output. Controllers have the most knowledge of platforms and operating systems. The views are pretty independent of whether their event comes from Microsoft Windows, X Windows, or any other.
And just as the views know their model, but the model does not know their views, the controllers know their views, but the view does not know their controller. *
The controllers were Smalltalk specific. They are not of general interest and are not covered here. For example, in a Java Swing architecture, a view and a controller are combined (this is often done in other architectures). In Swing, a combined view / controller is called a delegate.
* Read carefully and digest.
There is also (go through them):
"Confusion Models"
Smalltalk can then be reckoned with developing and promoting the MVC architecture. But he can also be accused of entangling things. The best acronym for architecture would be: M d M a VC.
M d : domain model.
M a : application model.
& about how the message should happen:
- View communication model.
- Model (and controller) to view the connection.
- An application model for communicating with a domain model.
I think this should give us a very clear picture. What is the actual pattern for MVC? .