I had a really frustrating conversation with some coworkers once about where to put some piece of code. We kept revolving about the same ideas for a while because they seemed unable to fathom that maybe, just maybe, there can be more layers in a system than models, views and controllers.
This, plus this talk from Gary Berhanrdt, made me very suspicious of MVC in general and controllers in specific.
Let me guess…Ruby on Rails?
Frameworks are often used as a crutch for poor design skills.
Hahaha, man, I’d kill for rails in that project. It was a java mess, with GWT in the frontend, to maximize suffering.
I think the author meant to refer to Alan Kay instead of Alan Key. Still, though it’s an interesting article doesn’t detract from it.
Thanks. Fixed that.
I love this post because its radical. It points out correctly that the view modifies the model correctly. People often mistakenly delegate that to the controller. Only purpose of the control is to orchestrate views. However I wish he went into more of Trygve’s latest work with DCI.
This is mostly due to the way web frameworks work. The router goes to a controller which can update the model.
Newer frameworks are starting to have a router call a function, which seems to bring us a bit closer to the original MVC pattern.
I read the first part of the piece thinking that it was trying to capture the “essence” of MVC in its original form. When I reached the conclusion, it seemed that the author was suggesting it doesn’t really matter. I like that message, and I think it’s the conclusion of the piece, but I wish it were written a bit more definitively.
My conclusion is little bit more nuanced and the last paragraph together with the meme image tries to communicate that.
Yes, in general it does not really matter. We agree on that. It is just a term and usually people roughly understand each other when they use it.
It does matter when you are actively trying to design something. If you “apply the MVC pattern” it might mislead you. Tonnydourado mentioned that “maybe, just maybe, there can be more layers in a system than models, views and controllers”. Don’t shoehorn your design into MVC. It is not a timeless pattern to which good designs gravitate towards. That matters because it introduces unnecessary complexity (thus technical debt) into your software.
What I meant didn’t matter is mostly the question of “what was the original MVC?”
I don’t have anything unique to add here, but I would like to say I went down almost this exact same trail of papers and reading after a bad project experience. The focus on MVC, and how it’s assumptions ended up falling apart because the design wasn’t well defined well, completely turned me off from huge swaths work.
Thanks for this very clear and detailed recap of the patterns. It reminded me how few people know of the PAC (Presentation Abstraction Control) pattern by Coutaz. PAC is hard to describe, but I think of it as a very fine grained hierarchical MVC. It is, I think, the best current model if you’re doing reactive or data flow driven UI programming.
| The model is identical to todays meaning.
The meaning has surely changed. Commonly today the Model is widely perceived as just “data”. Particularly data stored in a database
Contrast this with the model being an object model, independent of persistence. Today, unlike the original implementation, behavior is generally assumed to be outside of the Model.
| The Model-View-Controller (MVC) pattern is everywhere. Web frameworks use (it).