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.

Comments

Pedantry

[Anonymous Coward]

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!

Web Frameworks

[truthsearch]

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

[CodeBuster]

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.

Author is Pedantic

[iluvcapra]

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:Author is Pedantic

[LaskoVortex]

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 be said for MVC.

Of course I just committed the same omission as TFA in that I haven't defined exactly what I mean by the terms I use.

Re:Author is Pedantic

[plover]

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 something else like "P-BL-DA" for "Presentation / Business Logic / Data Access". (Or maybe DA-P-BL, in honor of the original screwing up of the order of the layers in the name.)

Re:Author is Pedantic

[KDR_11k]

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:Author is Pedantic

[KDR_11k]

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:Author is Pedantic

[Vornzog]

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 primary modules, it gets labeled MVC. It doesn't actually follow that pattern very closely, so the authors took to referring to it as MVT (model, view, template).

From the django FAQ:

In our interpretation of MVC, the "view" describes the data that gets presented to the user. It's not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It's a subtle distinction.

Where does the "controller" fit in, then? In Django's case, it's probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.

At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that's most logical to us.

Malcom is just pointing out that MVC comes with a lot of baggage, and doesn't really help to get stuff done.

Re:Author is Pedantic

[Chabil Ha']

...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.

Re:Author is Pedantic

[Shados]

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.

Re:Author is Pedantic

[mini me]

Sounds exactly like how Rails does it, and has been doing since long before PHPulse was ever released.

Re:Author is Pedantic

[lgw]

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.

Re:Author is Pedantic

[Shados]

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.

Re:Author is Pedantic

[lgw]

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.

wait a second!

[girlintraining]

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!

[mmkkbb]

The purest algorithms never touch a keyboard; only pencil, paper, and thought.

Re:wait a second!

[JCSoRocks]

No thought indeed. They really only involve butterfly wings flapping.

Re:wait a second!

[Hillgiant]

Paper is for sissies. If pressed, I just write it in the margin (provided there is sufficient space).

huh?

[larry bagina]

Since when did they let long winded douchebags with nothing to say have blogs?

Re:huh?

[daveime]

About 27 nanoseconds after the first blogging software was created.

Re:Model View . ..

[Anonymous Coward]

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

I like the prologue

[mattdm]

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

[styrotech]

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

[Fallingcow]

There's some evidence for that in their naming of the application layers:

Model
Template
View

Re:Django

[xfour]

DjangoCon 2008 - this was made entirely clear.. it's not a MVC architecture.. since the view does the application handling. Seriously guys.. seriously...

Re:Django

[Evdawg]

This is correct. The issue is in fact addressed in Django's official FAQ.

If you're hungry for acronyms, you might say that Django is a "MTV" framework - that is, "model", "template", and "view." That breakdown makes much more sense.

At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that's most logical to us.

Meh

[wezeldog]

I don't think the people behind Django would hold it up as a paragon of pure MVC either.
I'm assuming he pulled the uncited quote from the django book: http://www.djangobook.com/en/1.0/chapter05/
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

[omuls are tasty]

Umm, Malcolm is probably THE most active Django developer at this time (Django developer as in "someone who develops Django", rather than "someone who uses Django for development).

Wrong.

[Qbertino]

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.

Re:Wrong.

[plover]

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, specifically definition 2B.

Rather a lot like I'm doing now. </pedantic>

Re:Event Engine and Cross-Language

[AnyoneEB]

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?

MVC is good

[bytesex]

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!

[Qbertino]

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!

Re:Apply MVC (or any pattern) where it can be used

[CodeBuster]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

HWND Duck;

[mikiN]

If it walks like a duck, quacks like a duck, and runs on Windows, it must be an MVC application. --unattributed, possibly from Microsoftology, MCSE III

Re:Indeed

[Tetsujin]

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:Indeed

[jvkjvk]

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.

Glossary?

[Stiletto]

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

[marhar]

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

He seems to be a pretty remarkable character... still hacking at the age of 78, with a note on his new project:

"The new project could well be very large and take many years.... I will post intermediate and incomplete results as they appear. Just in case."

Have you every noticed?

[codepunk]

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

[GrouchoMarx]

I argued much the same thing 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.

MVC Hits AJAX: Splat!

[Adam Jorgensen]

I think MVC was a fairly valid pattern for web development prior to the development of AJAX technologies and the advancement of JavaScript as a language.

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.