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.
So let me get this straight: you're upset because some developers are misusing a term and giving their product more credit than it should have?
Well, that's never happened before!
The custom web framework my company uses helps program with the MVC pattern, but doesn't enforce it. Some developers are very consistent with separating the model, templating, and control structure. Some developers (not always the less experienced ones) often intermingle functionality and don't realize they're no longer within the MVC design. So our framework is nice that it's flexible, but it also will let you hang yourself. Most other frameworks, at least for PHP and Python, seem to be the same way.
Developers: We can use your help.
And does quite a bit of complaining about Django without completely demonstrating his point. I'm still foggy about his complete idea of what he believes the original interpretation of a "Controller" is, which is really the heart of the matter and where most people seem to disagree. His "model" of what MVC is is not explicated in his view, as represented by his blog post.
MVC is a pattern, not a set of rules, a coding style, house style, development framework, or development process. If you have three modules, one doing presentation, one doing state, and one mediating, you're doing MVC. What specific functions go where (is sorting on the model? is validation of this field in the view?) is specific to the problem domain.
IMHO
Don't blame me, I voted for Baltar.
I was under the impression that the Django team don't consider it to be MVC themselves, but they've just given up the losing battle of explaining the difference to the masses who think that MVC is the only good way you can arrange 3 different tiers of an application. So they've shrugged their shoulders and effectively said "Fine. If you want Django to be MVC, it is MVC. Now drop it and let us get back to developing it.".
Author is Pedantic
No he isn't. He critisizes the incorrect use and application of the term MVC and the misconception and the pointless enforcement of a wrong concept of MVC in places where it is often more than pointless to do so. Like in most modern web application scenarious.
And does quite a bit of complaining about Django without completely demonstrating his point.
No he doesn't. He uses Django as an example for all current hip Web FWs out there to emphasise the issue above. And he clearly states that before he even goes into Djangos documentation and concept of MVC.
We suffer more in our imagination than in reality. - Seneca
About 27 nanoseconds after the first blogging software was created.
MVC is good. When you understand it at its simplest. But it doesn't need a 'framework', which is where the confusion creeps in. Java is on the one hand so popular, yet so hopelessly constrained in its possibilities and libraries, that apparently this confusion seems to have become 'unrecognisable' as it were: people automatically postfix 'framework' behind 'MVC' because it's so difficult to build web-applications in java without one (well it's not, but they don't usually know that either).
A framework is a meta-language in essence, it 'sits on top' of your project. Libraries OTOH are (usually) written in your own language and 'hang below' your project (i.e. you use them, instead of it using you). Both can provide MVC, but both can provide many other things as well.
I prefer libraries me. I like to know where a request comes in, and be there when it happens. That said, libraries that model my data storage in nice structures and provide templating for output are yummy. But that's all - I feel the programming language should be *my* bitch, not the other way around. So yeah, I've had to write my own template rendering code since the existing ones all had unnecessary limitations rooted in the theory that the template shouldn't contain any code (so how are we supposed to go about iterations, theorists ?) or any complex variables (yet your data modelling library provides for those, thanks a lot !). Took all of a monday afternoon that.
Religion is what happens when nature strikes and groupthink goes wrong.
From Head First Design Patterns:
The beginner sees patterns everywhere. This is good. The beginner gets lots of experience with and practice using patterns. The beginner also thinks, "The more patterns I use, the better the design." The beginner will learn that this is not so, that all designs should be as simple as possible. Complexity and patterns should only be used where they are needed for practical extensibility.
As learning progresses, the intermediate mind starts to see where patterns are needed and where they aren't. The intermediate mind still tries to fit too many square patterns into round holes, but also begins to see that patterns can be adapted to fit situations where the canonical pattern doesn't fit.
The Zen mind is able to see patterns where they fit naturally. The Zen mind is not obsessed with using patterns; rather, it looks for simple solutions that best solve the problem. The Zen mind thinks in terms of the object principles and their trade-offs. When a need for a pattern naturally arises, the Zen mind applies it, knowing well that it may require adaptation. The Zen mind also sees relationships to similar patterns and understands the subtleties of differences in the intent of related patterns. The Zen mind is also a beginner mind, it doesn't let all of that pattern knowledge overly influence design decisions.
Have you ever noticed that guys that write subject matter such as this are the
ones that could not code themselves out of a paper bag?
mvc bla bla bla views bla bla bla models bla bla bla
Got Code?