Misssing Pattern in Model-View-Controller

MVC confusion must largely stem from the fact that the original MVC pattern was implemented in Smalltalk and in Smalltalk everything is an Object. With the Web this is not so. You have HTML, you have web-server, you have browser and you have database. It gets confusing trying to fit it all into "MVC".  Understanding Model-View-Controller is an example of a great explanation of Model-View-Controller for the Web. Still I think it misses one crucial part of MVC as originally envisioned, and implemented in Smalltalk.

What is the main point  of Smalltalk MVC  seldom included in descriptions  of "Web-MVC"?  It is not  that Model View and Controller are "separate". It is pretty obvious they should be. No spaghetti-code please. The main point is  what makes M V and C capable of working together EVEN THOUGH they are "separate"...

The original MVC solution for connecting the parts is the Observer-pattern.  A View subscribes to events broadcast by the model which are of relevance to that particular View. This means the model is unaware of the existence of the view, yet it is able to notify the view(s) when specific aspects of it change. Yes "aspect" is a key term in early descriptions of MVC.

The Model "broadcasts" events about changes happening to it. But implementation-wise the "system" must take care those events are propagated to the proper recipients. This  invisible part of MVC, its  event-delivery sub-system goes largely missing in most explanations of  "Web-MVC".

So, MVC is more than M + V + C.  It is M + V + C + event-delivery sub-system that allows M V and C to communicate with each other by event subscription, thus remaining minimally dependent on each other.

Another misconception must be that there is a Model, a View and a Controller. In the original Smalltalk  MVC a major emphasis was on the idea that there were MULTIPLE  VIEWS for each model, each displaying a different "aspect" of it, and having its own controller. Models are often composed of parts which tmelselves are models too. It is really more like Models-Views-Controllers. In Web-MVC the web-page is typically the one and only "view" presenting some underlying something, vaguely referred to as "model".

There is value in categorizing parts of any application into a Model, View and Controller. But that is not close to being the same as the MVC-pattern in Smalltalk.

A pattern is in the eye of the beholder. The pattern I see in Smalltalk called MVC is multiple Views presenting different aspects of the model, communicating with it via event-subscription, driven by user-interaction events produced by multiple Controllers, of different classes.  Controller modifies the model, model broadcasts information about changes to its different aspects, views that are "tuned in" to the specific channel for that aspect  receive notifications of changes to it, so they can update their state, their "looks" by asking the view for the current value or state of the "aspect" in question.

The essence of MVC is not that there is M, V and C. It is how the M and V and C communicate, with each other.

Links:
Understanding model-view-controller
Model-View-Controller
Observer-pattern

Copyright © 2017 Panu Viljamaa. All rights reserved 
https://twitter.com/panulogic