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.
Copyright © 2017 Panu Viljamaa. All rights reserved