Looking at Model-View-Controller in Cocoa
When Cocoa says Model-View-Controller it’s mostly trying to evoke the notion of Separated Presentation and Content in application design (the idea that the model and view should have a decoupled design and be loosely linked at construction). To be fair, it’s not just Cocoa that uses Model-View-Controller in this way: most modern uses of the term are really intended to convey Separated Presentation rather than the original Smalltalk-80 definition.
[…]
The important point to note is that the controller is the center of the object graph with most communication passing via the controller – distinct from the Smalltalk-80 version where the model was the center of the graph.
[…]
In my opinion, the critical failing for Cocoa Bindings remains the difficulty in adding custom transformations and custom properties. These could both be done but the work involved in registering transformers and exposing bindings dictionaries made a tiresome affair. It always just seemed easier to pass the data through the view controller without bindings. This meant that Bindings tended to help the simplest problems (that didn’t need much help) but didn’t have much impact on the harder problems.
Since Cocoa Bindings in Mac OS X 10.3, there haven’t really been any clear attempts by Apple to alter the design pattern used for Cocoa apps.
The problem with using the same name is shadowing: since the names are the same, accessing the original definition is now hard. Again, this wouldn’t really be a problem if it weren’t for the fact that the old MVC solved exactly the kinds of problems that plague the new MVC.
Previously: Model Widget Controller (MWC) a.k.a.: Apple “MVC” Is Not MVC.
