Model-view-controller (MVC) might be the only design pattern that means many things to many people. That’s why there have been already many patterns and approaches with at least a connection to classical MVC of SmallTalk community. The reason behind this is probably because classic MVC is not perfectly suitable for the applications having rich clients these days.

There are some certain rules that you should know and follow, but 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 changes to how data are manipulated from how they are 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 them. 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, each of the controls and the screen as a whole. So the first part of reacting to the user’s input is the various controllers collaborating to see who got edited.And then related part’s controller handle what happens next.

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 views and models, it is supposed to mediate 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 acoording 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 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 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 verse. (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.