Model-View-Controller — Misunderstood and Misused 221
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.
Re:Event Engine and Cross-Language (Score:3, Interesting)
GUI engines are outgrowing objects in my opinion. Objects are fine when you have hundreds, but not bajillions.
May I ask what you mean by that? I only have GUI programming experience in AWT, Swing, and a little GTK, and from those objects seem very natural for GUI programming. Your description of events sounds pretty much like those frameworks handle events, except you do have to think about how the event loop works due to threading issues, which seems like it could be fixed in the context of OOP.
How would you rather they be handled?
Re:Web Frameworks (Score:4, Interesting)
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.
Re:Author is Pedantic (Score:4, Interesting)
...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 [useit.com]. 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.
Re:Author is Pedantic (Score:4, Interesting)
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.
Interesting MVC notes by creator of MVC (Score:3, Interesting)
Here are some interesting notes from Trygve M. H. Reenskaug, who originated the term "Model/View/Controller" while at Xerox PARC in the 70's.
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html [ifi.uio.no]
He seems to be a pretty remarkable character... still hacking at the age of 78, with a note on his new project:
Re:Author is Pedantic (Score:5, Interesting)
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.
MVC Hits AJAX: Splat! (Score:2, Interesting)
However, with these developments the pattern applied by rote makes things seem simpler than they are.
From a perspective of working in web dev I tend to see things more as follows:
Model: The database and its DDL statements
Meta-Model: Server-side represenation of the databases stucture and data. The bridge between the actual Model and the Controller
Controller: Sever-side central code that fits into a grey area.
Meta-Model: Server-side reprsentation of the View.
View: What ends up in the browser. A combination of HTML and JS.
From my perspective, The Controller interacts with the Model via the Meta-Model to produce the View via the Meta-View.
The View, for its part, is capable of interacting with the Controller in turn thanks to AJAX and such interactions should be managed by the Meta-View.
This is overall a more complex scheme than basic MVC but is also, I feel, a little more representative of the actuality of things.