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.

Pedantry

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

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

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

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:

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

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

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

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

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.

Wrong.

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.

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>

Re:

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

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

wait a second!

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!

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

Re:wait a second!

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

Re:wait a second!

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

huh?

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

Re:

About 27 nanoseconds after the first blogging software was created.

I like the prologue

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

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

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

Model
Template
View

MVC is good

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.

Re:

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

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