You probably realized that there are many approaches or patterns differ from each other yet somehow have some connections with classical MVC of Smalltalk community. This is probably because, the classical MVC is not perfectly suitable for the applications having rich clients these days. Yet, there are still some certain rules that you should know and follow. However, depending on your preferences, coding style, or your project, you can introduce some differences. This is normal. It happened before, and it will happen in the future. You may even come up with your own MVC-based design pattern at some point.
MVC decouples how data is manipulated and how it is displayed or stored, while unifying the code in each component. For understanding MVC, we can consider that the model is the data or even activity. The model objects are completely ignorant of the UI/view. The presentation part of MVC is made of the two remaining elements; the view and the controller. The view is how we represent our data on the screen to the user, and the controller is the glue, the operator between model and view. The controller offers facilities to change the state of the model. Its job is to take the user’s input and figure out what to do with it. There is not just one view and controller, you have a view-controller pair for each element of the screen.
Usually, MVC and Observer Pattern are used together. The Observer is what maintains encapsulation and keeps MVC strongly object-oriented. Without the Observer, you need setters, which is considered as non-OO.
One common mistake is making the controller a god class, a class that does everything. The controller should not oversee the operation of the view and model, it is supposed to mediate the communication and unifies validation using either direct calls or the observer pattern.
Let’s take a look at how Glenn Krasner and Stephen Pope defines the controller in “A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80”:
“Controllers contain the interface between their associated models and views and the input devices (e.g., keyboard, pointing device, time).”
So, according to Smalltalk-80, the controller is a simple, well-constrained class that handle processing of the event loop for a particular view. But, in same cases (PAC, IMC. Java Swing, and so on) the controller may change a bit, or even unite with the view. This depends on what you need in your system. Sometimes, a pure Smalltalk-80 MVC may not answer your problems. So, do not fear to explore other variants of MVC, or even tweak it a bit. But always keep in mind, the controller should not be a god class.
Almost all computer games exhibit a very clear MVC, with a literal controller, which is physically separate both from the view and the modelling unit. Even if you introduce a series of controllers that creates a big system in the middle, when you look from the top, it is still a big controller between model (math side of the game) and view (rendering side of the game).
So, if we sum up everything:
- Model – The domain model, including data and procedures.
- View – What the user sees and controls; the final UI.
- Controller – The middle-ware and/or GUI framework that translates the Model to the View and vice versa. (A better name for this part may be “User I/O Manager”.)
And this is simply what model-view-controller is and there is one final thing to keep in mind. It is from Martin Fowler:
-
Make a strong separation between presentation (view & controller) and domain (model) – Separated Presentation.
-
Divide GUI widgets into a controller (for reacting to user stimulus) and view (for displaying the state of the model). Controller and view should (mostly) not communicate directly but through the model.
-
Have views (and controllers) observe the model to allow multiple widgets to update without needed to communicate directly – Observer Synchronization.
References