There are some interesting historical details in here but I have always thought and continue to think that MVC is a solution in search of a problem :)
Models and views have always seemed very clear cut to me, but IMO the controller is where we often run into trouble. It seems to invite framework / library designers to shoehorn various disparate ideas into this sometimes ill fitting abstraction, and as a result you can end up with some very cumbersome tools like J2EE.
The controller described in the original version of MVC is not something that users of GUI toolkits use today. It is handled by the windowing system. The more useful vestige that I generally refer to as a controller is parameterizing widgets like buttons or tables so you control their specific behavior (onClick, getLabel, isActive for a button, for example) by providing them with an object that implements those methods. This is how Cocoa uses it.
You’re right about people trying to shoehorn things into MVC without understanding the constraints its solving for. I think that those constraints are:
The views on the data must be able to operate and update completely independent of one another, so you need a choke point (the model) where there is an authoritative form of the data and views update based on that.
You want to be able to reuse views so that you have a consistent UI language, so you set up that visual language and let people wire up the semantics of the language in a specific case.
The Newton folks observed that the purpose of the controller is to avoid creating a specialised view for each model that it’s attached to. They then proposed that this is necessary only in environments where creating a specialised view is difficult. Their hypothesis was that class-based OO was a good fit for models (where you have many instances of the same class for different objects) but prototype-based OO was a better fit for UIs, where you want to adapt a generic view to your specific use.
Given how well JavaScript has done as a UI language, I’m inclined to believe that their hypothesis has some merit.
I’m inclined to agree as well. I have tended to pass in controller objects because I wanted to keep techniques to hand that worked in multiple languages, but prototypes are certainly an easier way. You can also do basically the same thing with anonymous subclasses in Java.
Most of them. Swing, Gtk+, Win32/MFC… The model/observer stuff isn’t really the GUI toolkit’s problem. It’s a way of organizing code. And they all have a way of specifying behavior of a widget for a particular case.
This is one way to look at it and your specific objections are clearly valid. I would also posit that another way to look at it is the MVC pattern is a natural outgrowth of separation of concerns albeit with ill-fitting demarcations. So, in Rails for example, you will often get a different flavor of the problem you outline with “skinny controllers and fat models”. I’ve seen this (and been responsible for) where the model object gets overloaded with responsibility and grows entirely out of control. In these cases, I find that MVC is usually the start of decent design but certainly not the end of it.
That’s a really excellent point. If I’m honest my opinions here are absolutely influenced by the fact that I have encountered way more ungainly MVC implementations than elegant ones, and perhaps I just need to be looking at or building the right kind of code-base to have a better experience with this pattern.
Looking at this across 40 years… It’s obvious that you must and at all costs separate your models and your views to build quality software. This is fundamental, and to fail to do so is to be completely, utterly, and hopelessly, lost.
This is quite a large book and I have only spent some time with it…. but I suspect you and I might have differing ideas about clarity.
After an hour, I’m having a difficult time pointing to any piece of this which would really help the discussion, though I suspect that anyone who was confused about MVC might benefit from a few weeks or months of careful study of this text.
Let me get back to you with my thoughts on this, it may be several years.
There are some interesting historical details in here but I have always thought and continue to think that MVC is a solution in search of a problem :)
Models and views have always seemed very clear cut to me, but IMO the controller is where we often run into trouble. It seems to invite framework / library designers to shoehorn various disparate ideas into this sometimes ill fitting abstraction, and as a result you can end up with some very cumbersome tools like J2EE.
The controller described in the original version of MVC is not something that users of GUI toolkits use today. It is handled by the windowing system. The more useful vestige that I generally refer to as a controller is parameterizing widgets like buttons or tables so you control their specific behavior (onClick, getLabel, isActive for a button, for example) by providing them with an object that implements those methods. This is how Cocoa uses it.
You’re right about people trying to shoehorn things into MVC without understanding the constraints its solving for. I think that those constraints are:
The Newton folks observed that the purpose of the controller is to avoid creating a specialised view for each model that it’s attached to. They then proposed that this is necessary only in environments where creating a specialised view is difficult. Their hypothesis was that class-based OO was a good fit for models (where you have many instances of the same class for different objects) but prototype-based OO was a better fit for UIs, where you want to adapt a generic view to your specific use.
Given how well JavaScript has done as a UI language, I’m inclined to believe that their hypothesis has some merit.
I’m inclined to agree as well. I have tended to pass in controller objects because I wanted to keep techniques to hand that worked in multiple languages, but prototypes are certainly an easier way. You can also do basically the same thing with anonymous subclasses in Java.
That makes a LOT of sense. Thanks.
Are there any frameworks or toolkits, either now or historically, that implemented this understanding of MVC?
Most of them. Swing, Gtk+, Win32/MFC… The model/observer stuff isn’t really the GUI toolkit’s problem. It’s a way of organizing code. And they all have a way of specifying behavior of a widget for a particular case.
This is one way to look at it and your specific objections are clearly valid. I would also posit that another way to look at it is the MVC pattern is a natural outgrowth of separation of concerns albeit with ill-fitting demarcations. So, in Rails for example, you will often get a different flavor of the problem you outline with “skinny controllers and fat models”. I’ve seen this (and been responsible for) where the model object gets overloaded with responsibility and grows entirely out of control. In these cases, I find that MVC is usually the start of decent design but certainly not the end of it.
To be fair, the MVC being described is local GUI interfaces, not the variation of it used by web frameworks.
A very fair call-out!
That’s a really excellent point. If I’m honest my opinions here are absolutely influenced by the fact that I have encountered way more ungainly MVC implementations than elegant ones, and perhaps I just need to be looking at or building the right kind of code-base to have a better experience with this pattern.
Looking at this across 40 years… It’s obvious that you must and at all costs separate your models and your views to build quality software. This is fundamental, and to fail to do so is to be completely, utterly, and hopelessly, lost.
All that mucky stuff in between though …
Adele Goldberg’s blue book is a fantastic testament to this lesson being clear from the get go.
This is quite a large book and I have only spent some time with it…. but I suspect you and I might have differing ideas about clarity.
After an hour, I’m having a difficult time pointing to any piece of this which would really help the discussion, though I suspect that anyone who was confused about MVC might benefit from a few weeks or months of careful study of this text.
Let me get back to you with my thoughts on this, it may be several years.