Slashdot Mirror
Model-View-Controller — Misunderstood and Misused
paradox1x writes "Malcolm Tredinnick shares a terrific rant against the misunderstanding and misuse of the Model-View-Controller design pattern. In particular he takes issue with the notion that Django should be considered an MVC framework. He says that 'It's as valid as saying it's a "circus support mechanism," since the statement is both true, in some contexts, and false in others (you can definitely use Django-based code to help run your circus; stop looking so skeptical).' I'm not sure I agree with the entire piece, but it is a very good read." We recently discussed another look at the bending and stretching of MVC patterns in the world of Web development.
Most other frameworks, at least for PHP and Python, seem to be the same way.
In fact, the only one that I can think of that is purposefully NOT that way is the Ruby on Rails framework which takes the path of "punishment" in the form of "ugly code" for those who attempt to deviate from the orthodoxy of the framework. In my opinion "punishing" developers for deviations is NOT the best way to promote your framework, but the Ruby on Rails disciples will not be convinced otherwise so I have given up trying.
...the idea that the view should never contain logic at all is quite dogmatic and as such doesn't work well on the real world...
I think that's what the OP is trying to say when he comments that 'MVC is a pattern'. Patterns help solve particular problems, but when following the pattern in the most purist of the sense doesn't solve the problem (or gasp! make it bigger!) then being 'pure' doesn't make sense.
Take AlertBox. I think there some gems in his usability suggestions, but if you follow his guidance to the 't', you end up with a boring and un-user-friendly site like his.
We're all hypocrites. We all have hidden parts, it's the contrast between them that make us more a hypocrite than others
Design patterns ARE obvious ideas. They're just obvious ideas people agreed upon and put into books. They're not standards of the ISO/Ansi type, they're just heavily agreed upon. Call it a convention, if you will. They're not used as a "cookbook" solution to problem: they're used so we can communicate common ways of structuting code better.
For example, it is much easier to say "I implemented the picture processing code of images using the Strategy pattern" than to say "I implemented the picture processing code of my images using an algorythm that takes an object in parameter which implements a specific, common interface which involves a particular method that will handle the format-specific processing which will allow us to more easily plug in new formats in the future". Design patterns make up a vocabulary thats commonly agreed upon, thats language agnostic, that is very often taught in schools, etc etc etc.
Until people started taking MVC as anything involving a model, a view and a controller, I could say "MVC model 2" to anyone (in the know), and knew -exactly- what I meant. Not anymore in this case (thus this article), but it still holds true for the core design patterns as described in most design pattern books, the most well known being "Design Patterns: Elements of Reusable Object-Oriented Software", which is one of the most well known references in software development and architecture. But if I look up "Adapter design pattern" on Wikipedia, in my "Design Pattern with C# 3.0" book, in the book I described above, or in my best buddy's university notes (who went to a different college as me), it all described the -exact- same thing.
Hope that answer your question.
Old-school developers liek myself have a significant problem with Design Pattern: they're new and confusing names for old ideas. Almost everything in the Gang of Four's book, for example, was some work-around for some limitation of C++. For example, I have to look up what the "strategy" pattern means, but I know how to pass a function in a language with first-class functions.
To anyone with a strong grounding in Computer Science, the Strategy pattern doesn't need a name - it's simply "The picture processing code of images takes a function as input".
And in any case mostof the fresh college hires I work with don't know what the "Stategy" pattern is (without looking it up) *either*, so giving it a name doesn't help the conversation at all. But I can tell them "don't hard-code your algorithm choices in a switch-case, store a pointer (function pointer, interface-typed pointer, whatever) as a member and call that" they understand both *what* I'm talking about and *why*.
With MVC in particular, it's received wisdom that all good GUI code is MVC, so of course all GUI code will be documented as ussing MVC. The clarity of term has been destroyed by the hype.
Socialism: a lie told by totalitarians and believed by fools.