Slashdot Log In
Model-View-Controller — Misunderstood and Misused
Posted by
kdawson
on Tue Dec 02, 2008 03:36 PM
from the more-mvc-than-thou dept.
from the more-mvc-than-thou dept.
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.
Related Stories
[+]
Developers: Web Browser Programming Blurring the Lines of MVC 303 comments
lkcl tips his in-depth article up at Advogato on the difficulties for the MVC programming model that are introduced by Javascript and AJAX, and solutions for them. He writes: "This article outlines how the MVC concept is made incredibly awkward by the gradual but necessary introduction of Javascript and AJAX. A solution is found in the form of Javascript Compiler Technology such as GWT or Pyjamas (PyPy's JS backend or Rb2Js could be used, with some additional work). The article outlines how and why the traditional MVC patterns are fragmented by Javascript and AJAX, advocating that if a site is programmed purely in a high-level language that is then compiled to Javascript for the Web Browser sections, the same high-level source code can be executed either client-side on the browser, or server-side, or even both, depending on the requirements. The implications of this approach are discussed in depth."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Pedantry (Score:5, Insightful)
Well, that's never happened before!
Indeed (Score:2)
Re: (Score:3, Funny)
I agree. This article was heavy on opinion and serves very little purpose. Who cares what this guy thinks about how certain, similar patterns are named?!
Well, in any case I'm very excited about this new "Circus Support Mechanism" (CSM) pattern... What's it do? I don't know! But it's cool!
Re: (Score:3, Funny)
Perhaps it's a new transport mechanism, designed to compress, transport and unpack data objects(we can call them "clowns"). The cool thing would be that you get more data out during the unpack stage than you'd ever think would fit in so small a transport (we could call that a "car"!).
There you go.
Web Frameworks (Score:5, Insightful)
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.
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.
Parent
Author is Pedantic (Score:5, Insightful)
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
Re: (Score:2, Insightful)
The model should handle all data, the controller should handle processing and the container should handle higher level functioning for gathering the model, the view and the container.
See PHPulse [sourceforge.net] as a very simple example.
Re: (Score:3, Insightful)
How do you reconcile view caching with this idea? I'm not arguing with you, mind you, but I'm wondering that if there's a cache involved does that immediately negate calling the pattern MVC? Another violation of this is AJAX. It has logic as client-side as you can get.
I think what the TF author might be thinking is that MVC means exactly this pattern applied at this level, and not scaling the pattern up to web server / app server / database server. Or if that's it, then we shouldn't call it MVC but s
Re: (Score:3, Insightful)
I think the idea is that the view is interchangeable and isn't expected to do anything in order to allow the system to function but it can of course have extra functionality that is not necessary but increases the userfriendliness. The view can validate the user inputs to spare the user some grief but the controller should never expect the view to behave in any way.
Re: (Score:3, Informative)
otho, the idea that the view should never contain logic at all is qui
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.
Parent
Re: (Score:3, Insightful)
Sounds exactly like how Rails does it, and has been doing since long before PHPulse was ever released.
Re: (Score:3, Insightful)
I'm still foggy about his complete idea of what he believes the original interpretation of a "Controller"
It's always good to define one's terms before one begins to write about them. If you ask 10 different experienced developers what MVC is, you'll get 10 different answers. The problem with this article is that we never get what the author's interpretation of what MVC really is.
But no matter what one's definition of MVC, its like OOP. With OOP, it has been said that any substantially complex system is actually going to require some sort of implementation of OOP, even if its hopelessly half-assed. The same can
Re: (Score:2)
And assuming at least one of them has it right, that means 9 people are wrong. MVC (original or model 2, thats about as far as defining it needs to go) is a documented software design pattern. By definition, software design patterns are meant to be standard, documented (thats the main part) ways of solving a recurring problem.
You may have a Model, a View and a Controller without having MVC. MVC or MVC Model 2 mean som
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.
Parent
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.
Parent
Re:Author is Pedantic (Score:4, Informative)
Seems like you have been mislead on a lot of concepts. Design patterns have ZERO (or very little) with the implementation. What they are about, is the intent. If most fresh college hires you see don't know Strategy, its time you look at hiring from different colleges, it is fairly standard, especially in software engineering degrees (a lot less in purist computer science schools, I'll admit).
Btw, while it is a possible implementation, it is actually uncommon (and not desirable) to implement Strategy by passing a function to a method, as that doesn't allow for a good upgrade path of the API (which is what Strategy is about).
Finally, not all good GUI code is MVC, far from it actually, as it doesn't apply well to event driven and composite application (the former is a large amount of desktop application, the later is also a lot of desktop application, and some heavily customizable web application package), in which case, one (out of many) prefered pattern is MVP, as MVC doesn't play well with the existing APIs and framework.
Finally, very few design patterns are "work around some limitations of C++", because, a gain, design patterns have nothing to do with the implementation, but everything to do with communication and intent. So Singleton in Ruby is actually built in, so you don't need to implement it at all. The concept of Singleton is still there when you talk about it. Observer in .NET doesn't need to be implemented, it is built in (multi-cast delegates). If your intent is to use Observer, thats still what is commonly talked about. And so on and so on.
They are more prevalent in certain fields than others, too. If you take a typical team that works on device drivers full time, you'll probably never find someone who has heard (much) about them, thats understandable.
Parent
Re:Author is Pedantic (Score:4, Insightful)
When I firt read Design Patterns 15-ish year sago, I was hoping for a book of insightful best practices, but instead found a bunch of ideas that were obvious to anyone skilled in the art, being given arbitrary names and then heavily obfuscated with UML. The majority of these "paterns" were things that were trivial to implement in (or just built into) other languages, but hard to do in C++. Somehow people thought this was ome major revelation. I still don't get that.
And IMO it did more harm than good, merely because people saw "singleton pattern" and reverted to heavy use of global storage claiming "it has to be OK, it's a design pattern". Sadly, that's the one that fresh college hires do seem to know.
Of course, I do work with device drivers and other "systems" code, not CRUD code, so maybe I'me just not in the right field to "get" these.
Parent
Wrong. (Score:4, Insightful)
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.
Parent
Re:Wrong. (Score:5, Funny)
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.
I think you just pretty much quoted the dictionary definition of a pedant [merriam-webster.com], specifically definition 2B.
Rather a lot like I'm doing now. </pedantic>
Parent
Re: (Score:2)
What specific functions go where (is sorting on the model? is validation of this field in the view?) is specific to the problem domain.
I'd be hard pressed to envision a scenario where field validation is logically a -view- function.
"If you have three modules, one doing presentation, one doing state, and one mediating, you're doing MVC."
But if your presentation module is mediating with the state then you aren't.
Re: (Score:2, Insightful)
I'd be hard pressed to envision a scenario where field validation is logically a -view- function.
High latency or intermittent connection scenarios where you can't check back with the controller all the time and it's better to avoid unnecessary calls if you can tell the user that the input is invalid anyway? Sure, the controller would of course still do validation but that doesn't mean the view can't tell you what's wrong without needing to connect to the controller.
Re: (Score:2)
High latency or intermittent connection scenarios where you can't check back with the controller all the time and it's better to avoid unnecessary calls if you can tell the user that the input is invalid anyway?
But that's funadmentally not doing MVC anymore. You've got the presentation (view) module is doing validation (controller function).
Sure, the controller would of course still do validation but that doesn't mean the view can't tell you what's wrong without needing to connect to the controller.
The 'cor
Re: (Score:2)
I'd be hard pressed to envision a scenario where field validation is logically a -view- function.
You've never programmed for a 3270 workstation, then. Basic field validation was part of it's firmware for the simple reason that users wanted fast, immediate feedback for basic errors (like trying to enter letters into a numeric field, or trying to put too many characters into a text field with a maximum size), and with block-mode communication between the workstation and the server that meant the workstation
Re: (Score:2)
Not really. MVC requires some very specific things from the layer that's doing the mediating. More often, you end up with something like MVP (Model-View-Presenter), or even something else entirely.
Re: (Score:3, Informative)
Author is Pedantic... And does quite a bit of complaining about Django without completely demonstrating his point.
Malcolm's blog assumes that the reader has a *very* good understanding of the django codebase. That's understandable, given that he rewrote most of the ORM prior to the recent 1.0 release, and most of his readers know it.
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 basic point is that no one actually knows what the controller *is*. The term is so poorly applied that it loses all meaning.
Really, this is a long standing point in the django community, and can be traced back to the original authors of the framework. Because django uses three primar
wait a second! (Score:5, Funny)
Wait a second, there's programmers that aren't using only pure algorithms, refined from the finest electrons, bred from the keyboard controller outputs of Bjarne Stroustroup himself? Well damn, standards are just slipping everywhere. What next, thinking of the web as a platform? Client-side security? Linux on the desktop?
Re:wait a second! (Score:5, Funny)
The purest algorithms never touch a keyboard; only pencil, paper, and thought.
Parent
Re: (Score:2)
The purest algorithms never touch a keyboard; only pencil, paper, and thought.
The purest algorithms wouldn't be constrained to any language that is composed of a finite set of symbols -- therefore, no pencil or paper. Probably no thought, either (at least, not limited human thoughts).
Re:wait a second! (Score:5, Funny)
Parent
Re:wait a second! (Score:4, Funny)
Paper is for sissies. If pressed, I just write it in the margin (provided there is sufficient space).
Parent
Re: (Score:2)
I think you meant Don Knuth
huh? (Score:5, Funny)
Since when did they let long winded douchebags with nothing to say have blogs?
Re: (Score:3, Insightful)
I like the prologue (Score:5, Funny)
As I started reading, I discovered I don't care enough to read the whole thing.
But I thought the beginning was awesome: "You can disagree with me only if you are wrong."
Django (Score:5, Insightful)
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.".
Re:Django (Score:5, Informative)
There's some evidence for that in their naming of the application layers:
Model
Template
View
Parent
Meh (Score:2, Informative)
I'm assuming he pulled the uncited quote from the django book: http://www.djangobook.com/en/1.0/chapter05/ [djangobook.com]
Here's another:
Taken together, these pieces loosely follow the Model-View-Controller (MVC) design pattern.
They don't seem to be too hung up on design pattern purity. Maybe it is different in IRC or the forums.
Re:Meh (Score:4, Informative)
Parent
MVC is good (Score:4, Insightful)
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.
Praise the Lord! (Score:3)
This guy and his essay on the issue at hand is a breath of fresh air in a ongoing onslaught of web-developement misconceptions that increased tenfold ever since countless Java freaks joined the fray with the hype called Ruby on Rails.
I beg all people to read it and read it well. Please.
May I quote one part:
In the MVC pattern, the Model is the application object. It contains all the presentation-agnostic, data-centric logic, which is often labelled "the business logic".
Yes. Say it again. Halleluja!
I'm glad I'm not the only one (Score:2)
I'm glad I'm not the only one. When I first came across the web-based use of MVC I kept scratching my head and alternating between "WTF?" and "You keep using that word; I do not think it means what you think it does." After a while I realized that the web framework community had just latched onto MVC in a sort of cargo-cult fashion, without regard for it's prior meaning.
Not that it's the first time such a thing has happened. Think "structured" and "object oriented" or even "secure." For that matter, c
Glossary? (Score:3)
Can we have a glossary or something? I've been programming (C, Assembly, some C++) for 10+ years and I have no idea what the author is talking about or any of the commenters here. Patterns? Templates??
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:
Have you every noticed? (Score:3, Insightful)
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
Not the first to say it (Score:3)
I argued much the same thing [garfieldtech.com] in much less space 2 years ago. :-) Most "MVC" web frameworks are anything but, and it is disingenous to claim that they are. It's a marketing gimmick for people that don't actually know what they're talking about.
Re: (Score:3, Funny)
I am intrigued by your Model View First post!11! software design pattern, and would like to subscribe to your newsletter.
I assume this pattern first involves thinking 'how is first ppost formed?' then going on to create a goatschema for the model, and finally rendering the first post by re-arranging the letters in some amusing way, e.g. fr1st p0st!!1
Re: (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: (Score:3, Insightful)
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 w