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.

Re:Web Frameworks

[Anonymous Coward]

I don't use Ruby or Rails, but I do like the idea of punishing deviant developers! Seriously, if there is a conceptual model around which a framework is based, going out on your own is punishing the other poor suck who inherits your code. Take the time to grok the concept and write to it. It's a good principle to make writing good code easy and writing poor code difficult.

Re:Web Frameworks

[Anonymous Coward]

I thought RoR was also a MVT framework, not a MVC framework.

Re:Web Frameworks

[Anonymous Coward]

Don't all frameworks use the MVC model? I mean I thought every developer has to Modify, Verify, and Compile in every programming project. Or am I missing something?

Ah, you mean MVC design and not work flow. Got it.

Re:Web Frameworks

[DragonWriter]

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.

This is only true to the extent that one views normal Ruby code as "ugly". Rails doesn't provide any extra elegance to code that doesn't follow its architectural assumptions, but then one could hardly expect it to do so. It doesn't do anything to make such code uglier, except by comparison to the streamlining it provides code that does follow its architectural assumptions.

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

[Foofoobar]

The view should do ZERO processing. That should settle it. Some templates allow for a minimal amount of if/else statements and some developers are just sloppy and stick in processing anyway when it should be moved to the controller.

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 as a very simple example.

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

[vux984]

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

[shutdown -p now]

If you have three modules, one doing presentation, one doing state, and one mediating, you're doing MVC.

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

[Shados]

If you ask 10 different experienced developers what MVC is, you'll get 10 different answers

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 something extremely specific. For example, MVP (Model View Presenter) also actually have a model, a view and a controller (among other things), but its NOT the MVC design pattern. The whole point of software design patterns is to have a standard vocabulary and preset documented ways of implementing solution.

If I talk about Adapter, Template Method, Abstract Factory, Strategy, or, yes, MVC, I mean something very specific, not a generic concept of a fuzzy way of doing things. You only need to define MVC if you're not using the commonly accepted definition of it. Ideally, you'd specify if you mean the original or Model 2, but if you're talking about web, it is almost (but not quite) certain you mean Model 2, so thats redundant too.

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

[vux984]

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 'correct' thing to do if you really want to be doing MVC in a high latency / semi-disconnected environment is to create distinct client and server MVCs. That way the client controller can tell the client view that the data is invalid without talking to the server. And when the client view hits submit, the client controller can pass the client model to the server controller for synchronization with the server model.

Re:Author is Pedantic

[B47h0ry'5 CuR53]

How do you reconcile view caching with this idea?

You could use a caching controller, which would handle view caching logic.

Re:Author is Pedantic

[Todd Knarr]

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 had to do that validation. You simply couldn't submit the entire form back to the server on each and every keystroke without killing performance. So the IBM designers gave the 3270 enough intelligence to do some of the processing locally, without having to send anything back to the server, and added a simple language to the form definition to allow for programming the workstation to do the needed validation.

Re:Author is Pedantic

[Dragonslicer]

Seems to me that the confusion here is about what exactly is the controller part in a web-based application. Specifically, that the controller is entirely on the server. When you add Javascript code to do things like validation, you're really adding to the controller, even though the code is on the client. The different parts of MVC don't always map one-to-one with computers. Even though they might match up in many systems, MVC and client-server are somewhat orthogonal.

Re:Author is Pedantic

[Jeff Hornby]

But now you're talking about the MVC Except pattern. In other words, it's MVC except for a few things we threw in there. So in the case you've cited, you've broken the MVC pattern.

That's not to say that what you're doing is wrong. In this case being slavish to a pattern creates worse software.

Re:Author is Pedantic

[Foofoobar]

View caching is done a variety of ways. You need to use the way that is best for your language and web server. As for AJAX breaking MVC, there is a solution. In PHPulse, the AJAX call is redirected back to the same page allowing the MVC framework to handle the AJAX call. This also allows all methods specific to the page to just be called thus not allowing the AJAX method to gain access to methods outside the range of the pages access (or outside the range of the users privilege access).

Thus AJAX calls still use the MVC framework in PHPulse.

Re:Author is Pedantic

[MichaelSmith]

Methodologies like MVC are fine when applied to the right problems. I work in air traffic control which is both distributed and real time. I see a lot of developers coming in from other fields and trying to match our application to one of another design pattern.

Then they stuff up.

Re:Author is Pedantic

[Fulcrum of Evil]

Or you accept that MVC doesn't work too well with high latency comms and come up with a different pattern - it's not dogma. Model/Client/Controller with Client doing view + some datascrubbing would work pretty well here. I'm not really comfortable with biz logic in the client, so let's not have that.

Re:Author is Pedantic

[Foofoobar]

Oh I see what you are saying. Since Ajax has processing, data handling, and view, where does it fit in? Well some say it is it's own separate MVC for presentation specific to the client and separate from the server (yet maintaining a symbiotic relationship with it). Hard to say. The web is a unique model that MVC was never prepared for. I think the browser itself will eventually have its own xcode gui builder tool that we will just send simple xml to and interact with. AJAX is merely step one to that process.

Re:Author is Pedantic

[imbaczek]

The view should do ZERO processing.

practicality beats purity.

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

[Hognoxious]

The separation of the business logic and the presentation is a desgn principle [at least] as old as CICS. It may be difficult for a snot-nosed little scrote like you to grok, but the different layers don't necessarily exist on different hardware.

Re:Author is Pedantic

[destiney]

Author is Pedantic

He seems directly in line with my own opinions of Django. It's really _not_ an MVC framework like many of it's users would have you believe.

And does quite a bit of complaining about Django without completely demonstrating his point.

One does not need to drink an entire glass of sour milk just to know it is sour.

Re:Author is Pedantic

[vux984]

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 had to do that validation. You simply couldn't submit the entire form back to the server on each and every keystroke without killing performance. So the IBM designers gave the 3270 enough intelligence to do some of the processing locally, without having to send anything back to the server, and added a simple language to the form definition to allow for programming the workstation to do the needed validation.

You've actually doubled up on MVC. The workstation you describe has its own local MVC which then communicates with the server which has its own controller / model.

Re:Author is Pedantic

[Mr. Slippery]

MVC (original or model 2, thats about as far as defining it needs to go) is a documented softare design pattern. By definition, software design patterns are meant to be standard

Documented by whom?

I've regarded the whole "Design Patterns" thing as 80% sound and fury, 10% obvious ideas restated in high-falutin' language, and 10% that might be useful to some people somewhere, so haven't paid much attention, but I'm really surprised to hear that there's some sort of official standard for them. ISO? ANSI? IETF? What's the standards board for "design patterns"? Thanks.

Re:Author is Pedantic

[agbinfo]

I've always seen this the same way as KDR_11k. That is, the model shouldn't assume that the view will validate the input. The validation, and other processing from the view, may simplify the user's interaction but the model can't trust it. This makes it possible to replace the view and keep the business logic. It also makes it possible to test the model independently of the view and controller. There's nothing wrong, in my opinion, to have intelligent views just as long as the model doesn't depend on them.

Re:Author is Pedantic

[mini me]

What good is a view that doesn't do any processing?

Let's look at this from a GUI application standpoint. Are you suggesting that drawing methods should live in the controller, or even the model? If so, what role does the view play?

As far as HTML generation is concerned, the place that you create the HTML is the view. You have to have at least some logic in this area unless your application is no more complicated than "Hello, World!"

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

[Daimaou]

I don't clearly understand the author's point of view either. Besides, everybody knows that Django is a Model-Template-View pattern and not a Model-View-Controller pattern anyway.

Patterns shmatterns. Django is awesome either way.

Re:Author is Pedantic

[Kent Recal]

Exactly. Reminds me of the old saying: "Dogmas are wrong, always.".

Django is a good example for the drawbacks of this approach since it went to the extreme and allows almost no logic in the templates - beyond the usual iteration and conditional constructs.

The result? It's a pain to develop with this part of django. Django constantly gets in the way here because you can't scribble even the smallest thing into a template to see if it works or "feels right", you have to fiddle with the controller or a custom filter all the time - and that becomes tiresome very soon.

This separation of concerns obviously makes sense in a settled application that is deployed in, say, the publishing business, where you don't want the template guys to accidently screw with production code. But it does not scale down to the building (or "evolution") phase of said application, or to very small teams where everybody is assumed to know what they're doing, or to applications where the separation is simply not needed at all.

Generally fast feedback and short cycles are most critical during development, especially in the webapp realm which is tedious enough due to the whole browser involvement. The last thing you need is artificial barriers while trying things out and shaping up...

Re:Author is Pedantic

[Foofoobar]

Depends on what kind of 'drawing' you are talking about. Drawing a picture via a backend class? Yes abso;utely via the controller and perhaps even th model should you need it. Interactive drawing? Well if done vie flash or java, again, you would separate the components again. Done via AJAX, you would separate this out again.

AJAX needs to be treated as it's own MVC layer; as being separate but symbiotic with the server side. This is why jQuery is referred to as a framework... because it essentially is. But people need to build MVC for it. So don't think that just because you have an interactive component in your website, that it isn't MVC. It should be MVC in it's own way for ease of development and ease of use.

Re:Author is Pedantic

[ozphx]

Field validation is not a view function, agreed.

The view is obviously allowed to understand what is being viewed. So the view can provide "friendly" services, like providing popup calendars on edit boxes, or even simple "pre-validation" on input fields. Hell, if you like the view can grab the correct service interface and lookup the damn 3D model of the widget being edited.

The controller should not rely on the view to perform any validation. As long as the controller controls the view only via its interface and action events come back out, and, importantly the view does not fuck with the model directly, then it doesnt matter what it does.

Basically when you implement IWidgetEditingView in the most naive way, you should not be able to break the controller/model. (And thus be able to unit test the controller easily, confidently swap view implementations because stupid-client-b wants dicks on his screen, etc).

Re:Author is Pedantic

[Foofoobar]

Again to classicly show my point, PHPulse has AJAX built in so that ALL AJAX calls get routed back through the MVC framework to use the same classes and methods that were used to build the page. That way the AJAX method cannot access any classes or methods that the user does not have access to. You can integrate it in and have the container/controller and model handle everything with AJAX being it's own separate (but integrated) layer.

More frameworks need to follow the lead of PHPulse by doing it this way. I've only seen a couple start to do this but they are doing it rather clunky due to not universally managing privileges through the framework.

Re:Author is Pedantic

[Anonymous Coward]

To render "Hello, World!" I'm pretty sure takes some serious logic to calculate the pixel offsets, anti-alias the font, not to mention the view handling, window handling, os logic, display driver logic etc etc.

Grandparent did not think his cunning plan all the way through.

Re:Author is Pedantic

[Anonymous Coward]

He seems directly in line with my own opinions of Django. It's really _not_ an MVC framework like many of it's users would have you believe.

Ya THINK? I'm not going to post the link because so many other people have already posted the link, but they call it a MVT framework.

Re:Author is Pedantic

[mini me]

Since Cocoa pushes MVC, I will use it as an example. The drawing I am talking about is the stuff that happens in the drawRect method to be shown on the screen. This, as far as I am concerned, is the view.

As I said, if you pushed that logic out into the controller as the grandparent suggests, why would MVC even need a V?

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

[Foofoobar]

Yeah but PHPulse scales. Seriously though, if you want to go down that road, you would see that PHPulse has the highest benchmarks for speed and scalability in a PHP framework. So while RAILS may have had that for years, PHPulse has scaled for years. Come talk to me in 5 years when Rails can do that and work in the enterprise.

In fact, most Ruby sites use PHP still in order to scale. And yet, somehow, Ruby fanatics still deny this to this day... sad really.

Re:Author is Pedantic

[Anonymous Coward]

The view should be const.

Processing (sorting, computing summary statistics, changing grouping) in the View is fine, so long as it doesn't modify the Model.

Re:Author is Pedantic

[Anonymous Coward]

And does quite a bit of complaining about Django
 
heheheh... you do realize he's a core contributor?

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

[mini me]

There is nothing about Rails that prevents it from scaling. Anyone who claims that Rails does not scale obviously does not understand what scaling means.

Also, I am certain I can write PHPulse code that does not scale.

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

[Anonymous Coward]

View should not handle any more logic than that which is required to view. It should do no processing of its own, merely act like a dumb terminal.

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.

Re:Author is Pedantic

[daniel_newby]

Django is a good example for the drawbacks of this approach since it went to the extreme and allows almost no logic in the templates - beyond the usual iteration and conditional constructs.

Which is just a default, not a policy. Django templates are cleanly isolated from the rest of the framework, so any sensible Python template renderer can simply be plugged in. Here's an example of Cheetah templates being plugged into Django with a dozen lines of glue code. Mako looks like it would be trivial to plug in too.

The result? It's a pain to develop with this part of django. Django constantly gets in the way here because you can't scribble even the smallest thing into a template to see if it works or "feels right", you have to fiddle with the controller or a custom filter all the time - and that becomes tiresome very soon.

What's wrong with jamming in some "lorem ipsums", fiddling until it renders prettily, then building the necessary view? You can dive in even before the models are built.

This separation of concerns obviously makes sense in a settled application that is deployed in, say, the publishing business, where you don't want the template guys to accidently screw with production code. ...

An even better property is that it forces the software engineer to separate the logic from the presentation, no laziness allowed. That makes it dead simple to reuse the logic for any number of presentation formats. For example, suppose you make a web page that shows a completed e-commerce purchase. With more templates and a few lines of glue code, the logic can be trivially reused to generate an e-mail copy of the order form, a .csv for the accounting system, a WAP version, shipping labels, a packing list, a PDF RMA label, and so forth.

This is critical for maintainability. With a typical PHP-like system, there is an almost irresistible temptation to copy-and-paste code to make multiple presentation documents, a recipe for unfixed bugs and version drift. This potential problem is why Django is very big on the DRY principle, Don't Repeat Yourself. And still it is not mandated, just a handy default that steps aside if you know better.

Re:Author is Pedantic

[Anonymous Coward]

you get the consolation cookie for completely missing the point.

Re:Author is Pedantic

[DanyX23]

It's not that black and white. Yes, generally a view should do no processing, but e.g. localization is something that can legitimately be considered a job of the view and is of course something that changes the data (think date formatting etc). GP got it right, it's a pattern, not a religion. As long as it's well understood by all members of a dev team what they think makes up a pattern and Grey areas like the on I just mentioned are discussed among them, everything is fine.

Re:Author is Pedantic

[LizardKing]

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.

As someone who has done a fair bit of CRUD code, the Singleton pattern is rarely appropriate there either. Taking a Java web application as an example, it is far better to not write CRUD classes as Singletons and to use a Dependency Injection framework to pass parameters to them. Writing data access classes in this way makes them easier to test and mock, as hiding Singletons behind an interface is never as elegant as doing so with classes that you can directly instantiate.

I also agree with your criticisms of the Gang of Four book - although it was a reasonable step forward at the time it was first published, it was rendered less useful by excessive use of UML and reliance on C++ for most of the examples (admittedly it was the most commonly used OOP language at that time). I do admire the authors attempt to create a common "vocabulary" for programmers, that would allow them to express common idioms in a way that would be immediately understood by their peers, but a little more criticism of certain patterns would have been good. As you say, it's much too easy for someone to use the Singleton pattern inappropriately, and justify doing so simple because it's in the GOF book.

For my own work, which revolves around Java these days, something like Martin Fowlers "Patterns of Enterprise Application Architecture" is a much better book than the GOF one. Fowler is far more critical of the patterns he describes, and his writing suggests someone with far wider ranging experience of applying the patterns than the GOF authors who seem to have based their entire work on an academic proof of concept (the InterViews GUI toolkit).

Re:Author is Pedantic

[hey!]

Well, you might not like pedants, but they play an important role. People use terms like MVC as if they were magical talismans.

My beef with MVC is that it is so often part of a "pattern first" design approach. The MVC fairy dust is so often chosen, and then assumed to be doing its magical job. If you look you find all kinds of bleeding of responsibilities across classes until the pattern exists formally but not practically. This is particularly true when you select the pattern by selecting a framework that "provides" this pattern for you.

In an ideal world, MVC would be common, but not have a commonly recognizable name.

I think it is most important to see patterns as part of a development process. It's OK to mix presentation and business logic code early in the process, although obviously not ideal. The important thing is that every time you work on a piece of software you clarify it and gather distributed assumptions into central locations. That process will naturally generate MVC along the way. The key is to reduce the net coupling of the system components as the system grows.

Re:Author is Pedantic

[Anonymous Coward]

Go back to php then. What's so hard? You deliver data to a template and the template presents that data.

Re:Author is Pedantic

[Foofoobar]

And yet somehow, CTO's and larger companies dump RUBY and Rails for that simple fact and stick PHP, Perl or Python on the backend to act as a crutch when TRYING to make it scale.

As for writing back code that doesn't scale, that's a developer issue and not the framework issue as you know. PHPulse is used in the enterprise by investments firms and by telecoms for day to day business. Rails is used for small mom and pops. So I reiterate... call me in 5 years when you can get the language to scale.

Re:Author is Pedantic

[Kent Recal]

Which is just a default, not a policy. Django templates are cleanly isolated from the rest of the framework, so any sensible Python template renderer can simply be plugged in. Here's an example of Cheetah templates being plugged into Django with a dozen lines of glue code. Mako looks like it would be trivial to plug in too.

True. We use jinja most of the time (which has of the best of django templates, minus the hassles), and genshi for XML composition. I picked out django because I judge it by the defaults it ships with and the recommended best practices. Yes, pretty much any web-framework can be shoehorned into something completely different but the further you depart from the intended use, the less can you benefit from the overall integration.

What's wrong with jamming in some "lorem ipsums", fiddling until it renders prettily, then building the necessary view? You can dive in even before the models are built.

As said, there's nothing fundamentally wrong with that (and often the separation is desirable), it's just a hassle during developement and should at least be optional. The fastest way to prototype a webapp is usually to throw some code into the template - django forbids that. I'm not saying that a serious amount of work should be done in the templates, but it really helps in the building phase and even in production code it doesn't hurt to have the occassional "d = new Date()" or such in a template. Sticking small snippets of logic into the template can often make the end-result *more* pluggable, by not the concerning controller with low-level view details.

An even better property is that it forces the software engineer to separate the logic from the presentation, no laziness allowed. That makes it dead simple to reuse the logic for any number of presentation formats. For example, suppose you make a web page that shows a completed e-commerce purchase. With more templates and a few lines of glue code, the logic can be trivially reused to generate an e-mail copy of the order form, a .csv for the accounting system, a WAP version, shipping labels, a packing list, a PDF RMA label, and so forth.

Force can be good for newbies (force them to do the right thing) but once you're beyond that it becomes a two-bladed sword. As I outlined above, sometimes it *is* better to move a small snippet of logic into the template, for the very purpose of pluggability. A general purpose controller for all the views that you described above will likely be quite loaded with presentation details (PDF renderer etc.). Moving these details to the actual template *can* be a better solution in the long run because it keeps controller complexity down and ideally you won't have to touch the controller when you add new views. Again, I'm not advocating that this is always the way to go (it obviously isn't when you need to have non-programmers work on the templates), I'm just saying that there it is a valid choice that shouldn't be banned for the sake of purity.

Re:Author is Pedantic

[Foofoobar]

You have a very good point. It is dogmatic. However in a shop of 5 developers, your code should be easily interchangeable and one developer should not have to guess where the other puts his functions. If they are always put in the controller, then this is a very easy place to find them.

What you are talking about when you mix AJAX is two separate frameworks however; the client side framework and the server side framework. I would argue that for ease of maintainable code, AJAX functions need to be separate from the view but used by the view. Having all your functions in your views makes them hard to reuse. This allows for the symbiotic relationship between the two frameworks to be maintained through the view and still allow for the reusability and maintainability of the code. AJAX needs to be treated as a separate by symbiotic framework for the client side.

Re:Author is Pedantic

[mini me]

Let's hear some names. Yellowpages.com claims that Rails scales without any problem. Twitter, despite all their whining, seem to be scaling just fine also. Which PHPulse sites have more load than those two?

Re:Author is Pedantic

[julesh]

The view should do ZERO processing. That should settle it. Some templates allow for a minimal amount of if/else statements and some developers are just sloppy and stick in processing anyway when it should be moved to the controller.

Strong disagree.

You don't want to make the model responsible for calculating all the different information that a user might want to view about it. Say your model is a list of numbers (scores for a sports team, perhaps). Some users want to see statistics: average, high, low, median scores. standard deviation. Should the model calculate those for the view? I don't think so. The model should be straightfoward: it should be concerned with only storing the data that is required to be stored and ensuring it remains consistent with the rules that are placed upon it. The model is the most important part of the application to get right (because data loss can occur if it is wrong), so it should be kept as simple as possible.

In this case, I would say that the TeamScores model class should merely implement the basic functions required to access the basic information (e.g., it should probably be able to return an array, collection or iterator of scores). This would then be passed to a ScoreStatistics view class, which would generate the required information and package it in some simple manner (e.g. by storing references to values in a map of some kind, or in less dynamic languages like Java you could store appropriate component-type objects, e.g. JavaBeans, in such a map), and pass this packaged information to the presentation layer (e.g. a templating engine).

The view, IMO, should normally remain separate from both presentation and model.

Re:Author is Pedantic

[Foofoobar]

Heh That's not what I heard about Twitter. I keep seeing them go down CONSTANTLY! And people constantly have problems connecting. And they aren't even doing that much.

As for Yellowpages, you mean WHITEPAGES and they haven't started implementing Ruby yet so your point is pointless. They are still a Perl shop. They just used it for a small project and it still didn't work that well and uses massive Perl on the backend... as does Twitter.

So again... I fail to see your point. If Ruby needs all this Perl to back it up, how does it scale so well again?

Re:Author is Pedantic

[Foofoobar]

Face facts Ruby-nooby... without PHP, Perl or Pyhton to back up Ruby, it can't do squat. Every reference you are going to throw at me uses PHP, Perl, C, Python or some other language on the backend to handle the grunt work. Ruby is just a toy language for handling HTML. It's great for non-programmers and non-developers or small shops. But for businesses that need to grow, code that needs to scale, applications that need high availability, it has at least 5 more years. This is why most developers with any amount of experience say this and why developers with little or no experience like yourself keep denying it.

Now here is where you quote some questionable credentials saying just how experienced you are to have made you move to Nuby...

Re:Author is Pedantic

[searlea]

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

PebBLe DAsh has a nice ring to it!

ewww...

Re:Author is Pedantic

[mini me]

Your argument makes little sense. Even your PHPulse framework requires the use of other languages on the backend. At least according to the website.

And I still want to hear some names since there are, by your own admission, a lot of large companies using it. Does Facebook use PHPulse? Digg, perhaps?

Re:Author is Pedantic

[Foofoobar]

And what other languages would that be hmmm? Javascript? LOL. Let's see you do AJAX without it, Ruby Nuby.

As for it being my framework, I never said it was. I just happen to use it.

Re:Author is Pedantic

[mini me]

You said backend processing, not frontend processing. Backend would include MySQL, which apparently is a PHPulse requirement, and just so happens to be written in C, not PHP. It also uses the SQL language.

It would be insane to think that Ruby, or even PHP, is the right tool for every job. And not even your entire stack is written in PHP, despite your efforts to claim otherwise.

Also, I'm still waiting on those names. You made a big deal about the vast number of large businesses using PHPulse, so naming one or two that use it publicly should be easy. I already gave you a couple of the more well known Rails users.

Re:Author is Pedantic

[mini me]

Umm, no I am definitely talking about Yellowpages.

Facebook has the same problems you mention that Twitter has. Since Facebook is a PHP shop, by your assertion, PHP cannot scale either.

Re:Author is Pedantic

[Foofoobar]

Yeah and most people consider that a language like XML is a language. Get serious. You really are a Nuby aren't you? You aren't even worth my time. Go troll elsewhere Nuby.

Re:Author is Pedantic

[Foofoobar]

Again, not my stack. PHPulse was written by Owen Ruble. I just happen to have implemented it at the telecom I work for for a 10 terabyte database connecting a couple million users a day over. Ruby chokes and dies. Other PHP frameworks choke and die even. PHPulse was the only one I could find that would scale and it does that REALLY well!

As for not doing eveything well... major duh there Nuby. You don't use a web framework for application development and vice versa. But a web framework SHOULD scale with your website and you should merely need to add hardware or tools and not REPLACE the language or framework which is the case that many CEO's has found out with Ruby.

You are merely another Ruby Nuby in denial as every Ruby Nuby is. This is why the Ruby Nuby buzz has died and people have started turning away from it... because the hype doesn't match the languages capabilities. It is still a Nuby language. Deal.

Re:Author is Pedantic

[mini me]

Of course XML is a language. What do you think the L stands for? Are you going to tell me that english is not a language next?

Re:Author is Pedantic

[mini me]

Since you claim to have experimented with Rails on your project, would you mind telling me what, exactly, prevents it from scaling?

I understand that fixing the problem may have been more difficult than starting over with PHPulse, but no logical person would throw out all that hard work without a good understanding of why it doesn't scale.

Re:Author is Pedantic

[Foofoobar]

Excellent... program me something in it then. Next you will be telling me because the framework uses Apache, it relies upon C. Get serious Nuby.

Re:Author is Pedantic

[Foofoobar]

Go ahead and write a program in SQL or in XML, there NUBY. Feel free to show me how those are programming languages. I love to see Nuby's show their ignorance.

Re:Author is Pedantic

[Foofoobar]

Most industry leaders say the more dynamic a language, the more resources it must use and the less flexible it becomes. Few would argue with this hypothesis. I leave it up to you to continue to argue with industry leaders.

Re:Author is Pedantic

[mini me]

XML is not a programming language. I never said it was. I'm not sure where you got the idea that you could write a program in it came from.

I can write you a program in SQL for you.

SELECT foo FROM bars;

Now I can already hear you thinking that this isn't a program because the RDBMS is doing all the work or that SQL isn't turing complete, even though it is under most implementations. But it is a program as much as the following is a program.

<?php echo "Foo"; ?>

Now that I have presented you with examples and programs, let's see the list of companies who have achieved great success scaling PHPulse well beyond what Yellowpages.com and Twitter are doing. You only have 500 businesses to chose from, according to Alexis, so it shouldn't be too hard of a list to compile.

Re:Author is Pedantic

[booch]

He said XML is a language, not a programming language. And why do you insist upon calling all Ruby users "Nuby"?

Re:Author is Pedantic

[mini me]

Industry leaders means about as much as CEOs. Without naming names to verify your statements with, your comments do not hold much credibility.

However, some benchmarks show that Ruby is faster than PHP. Once MagLev hits the streets Ruby will be significantly faster than the current runtime. Granted, benchmarks do not mean a whole lot outside of the real world. Since we are not talking about performance, but scaling, that point is moot anyway.

As a reminder we are talking about scaling here. What prevents Rails from scaling? Since you have, admittedly, worked with it in the past, you should be familiar enough with it to know what prevents it from scaling. Hearsay alone does not prevent it from doing so, I'm afraid.

Re:Author is Pedantic

[daniel_newby]

Those are good points. I wonder what amount of template "power" would be optimal? Preventing changes outside the template's own variables would eliminate most mischief. Arithmetic is nice, and a major shortcoming of Django templates. Defining new classes is probably excessive.

Must stop designing ... new ... language ...

Re:Author is Pedantic

[Kent Recal]

No need to reinvent the wheel here.
As said we use jinja for our general templating because it provides all the django niceness plus full power and no limitations.

In the few areas that we want to give out to non-technical designers (or even untrusted users) we just use genshi. The genshi syntax is fairly ugly but has the advantage that a) it is pure XML so we can validate it to make sure it doesn't blow up the surrounding page and to protect against mailicious HTML/javascript and b) there's a toggle to completely sandbox it, just like django templates, so template designers can not execute any code that we don't like.

There's nothing stopping you from using two or even more template languages in the same app - right tool for the job. :-)

Re:Author is Pedantic

[syousef]

I'm glad I'm not the only one that thinks Design Patterns are just double speak.

I sat down once and started creating simple example implementations of each pattern in Java. I got through 8 or 10 before losing interest. It did make me a little more familiar with the patterns, but what really irked me was that in some case the difference between two patterns was the "intent". That alone speaks of over-complication when you need multiple phrases to describe the same idea and some subtle and subjective intent is the only difference.

However what I find worst about patterns is that whether or not programmers understand them they try to employ them anyway and end up with a overly configurable overly complex mess that they don't understand with awful performance because they've tried to cram every damn pattern in the book into their code.

The crux of the problem is this: Design patterns outline a solution for a problem that may or may not be relevant to the system you're working on and because patterns are flavour de jour people cram them into their code without ever doing a proper analysis. Couple this with XML configuration for everything (whether it needs to be configurable or not, just in case!!!) and you've just described the J2EE world in 2008....but wait there's more - lets shoe horn new language constructs like annotations into the mix, because code you can't follow in a debugger (sorry correct term is is code that addresses "cross cutting concerns") is soooo much better.

Re:Author is Pedantic

[try_anything]

This is the most valuable post on the page by far, because you only have to read the ensuing discussion to see that the article is correct. Developers who share a common belief in the supremacy of MVC as a pattern can't agree on what Model, View, and Controller mean, even in simple, commonplace situations.

Re:Author is Pedantic

[Anonymous Coward]

That's not MVC any longer, but "three-tier" architecture. In a pure MVC pattern the view freely interact with the model.

Re:Author is Pedantic

[danieltdp]

One of the things I stumble with MVC is the following. First, note that I am talking about desktop applications, and not web...

The view is supposed to present model's data, right? Should the view do it by directly observing the model or the controller should observe it and then notify the view if something changes?

Re:Author is Pedantic

[danieltdp]

Replying to myself. How bad is that!? Well, I've done my homework and learned a couple of nice things on the subject.

On classic MVC, each widget is decomposed on a View/Controller pair. Controller changes model, view get updated by observing model.

Then you have MVP (model view presenter), which defends that you are supposed to have sort of a unique controller for all widgets. The controller part of each widget get the event and calls the presenter (main controller) to ask for a chance at the model. Still, the view part get updated by notification. It observers the model directly. This way, much of the logic that would end up dispersed on a couple of small controllers would get bunched together at the Presenter (main Controller)

The final twist is when you have a Passive View. This is a View that is as dumb as possible. It could even stop listening to the Model. On this case, the controller should observe the Model and update the Passive View accordingly

Re:Author is Pedantic

[DragonWriter]

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

Some books focus on pattern implementations in particular languages (either explicitly, or implicitly because of the patterns chosen), and tend to focus on patterns that need substantial implementations because the languages on which the book focuses can't implement them in a simple, elegant manner or in a form which is readily adaptable to a library rather than a repeated code pattern.

OTOH, other works focus on design patterns as elements of design (as the name "design patterns" suggests), not in terms of language-centric implementation (though they may provide concrete examples, and may talk about implementation in terms of pattern composition.) A good example of this is Enterprise Integration Patterns.

I'd argue that the latter types of works are the ones which focus on the design patterns as design patterns, and are the ones that actually do help provide a common language for discussing approaches to solving a problem.

Re:Author is Pedantic

[Foofoobar]

The need for you to verify my statements when you have yet to accept the reality that many people have ben stating for years now about RUBY means very little to me. Your inability to deal with reality should be your greatest concern and I would suggest counseling and/or medication.

Re:Author is Pedantic

[Foofoobar]

Oh god you are a tard. Two posts ago you stated 'what do you think the L in XML stands for?' and now you try to backpedal??? Total NUBY. Your employers are so lucky to have a highly qualified janitor like you at their disposal.

Re:Author is Pedantic

[mini me]

Thank you for your concern and advice. Would you mind providing a list of counselors, medications, and major PHPulse users to aid in the treatment of my condition that you have so graciously diagnosed for me?

Re:Author is Pedantic

[mini me]

XML is most certainly a language. That is, like I earlier stated, what the L stands for. It is not a programming language, of course, but your original reference to XML made no mention of programming. English is also a language, but I have no intention of writing a computer program in it either.

Re:Author is Pedantic

[Foofoobar]

Oh my god make up your mind. This is like arguing with a three year old schizophrenic. It is a language, it isn't a language, it is a language.

So if it's not a programming language (and neither is SQL), why are you comparing it to them? Why would you say that PHPulse also relys on other languages like Perl when you have just stated that SQL and XML are not programming languages? Ruby relys on other languages to scale; PHPulse scales indefinitely on it's own.

You logic is flawed much like your brain.

Re:Author is Pedantic

[Foofoobar]

For info on that you would have to contact the owner of the project. I only know the two companies I have installed at. Now seek some help for your parents sake so they can have their basement back.

Re:Author is Pedantic

[mini me]

You claimed that "PHPulse is used in the enterprise by investments firms and by telecoms for day to day business."

Investment firms (plural) and telecoms (plural) means that at least four major businesses are using it. Yet you now only know of two. Perhaps you could explain what happened to the other two, or more, businesses that were using PHPulse?

Re:Author is Pedantic

[Foofoobar]

Hey Ruby, can't make it Scale?

Take a real lang and make it better.

Remember, your bloat is due to your code

Flush it down the commode and it will be better.

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!

[Evanisincontrol]

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!

[JCSoRocks]

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

Re:wait a second!

[dollargonzo]

I think you meant Don Knuth

Re:wait a second!

[Hillgiant]

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

Re:wait a second!

[fbjon]

The Universe is the only real algorithm anyway.

Re:wait a second!

[Kent Recal]

Welcome to the real world, I guess.

Re:wait a second!

[the-matt-mobile]

In theory, there's no difference between theory and practice. In practice, there is.

Re:wait a second!

[Anonymous Coward]

"Oh Yeah! Good ol' C-x M-c M-butterfly"

emacs+xkcd: it's funny, stupid mods.

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

Re:I like the prologue

[Anonymous Coward]

Why read the prologue when you can skim it, misunderstand the author's point, and be snippy about it on Slashdot? It's faster that way.

The actual quote you're referring to, regarding whether there's disagreement about the term "MVC":
"It seems to be traditional to add a note that if you disagree with me, that's fine. In this case, though, if you disagree with me, you're claiming that there's no ambiguity or misunderstanding or misuse of the term and pattern MVC. Since there's lots of evidence to the contrary, I would suggest that if you disagree with me, you need to do more reading. I'm not taking sides (here) on which of the many alternatives might be correct; I'm identifying the problem."

There are people who find the term ambiguous, and some who find it perfectly clear. Even among those who find it clear, there are a number of differing views. The author's point is that it's hard to deny there's at least some ambiguity in this context.

Re:I like the prologue

[Anonymous Coward]

But I thought the beginning was awesome: "You can disagree with me only if you are wrong."

Having RTFA, the best part is... he's right.

Re:I like the prologue

[colmore]

There's an old way of using the term that refers to a way of making GUI desktop apps in an object-oriented language. There's a newer use of the term, or a synonym that describes a broadly similar way of structuring applications that is different in many key technical ways, but similar enough that a variety of people have felt comfortable applying the term.

Re:I like the prologue

[Bill, Shooter of Bul]

Yeah, but that in of itself is no excuse for the article he wrote. There are people who find the term "ambiguous" ambiguous. Its a cheap trick. Define the terms for my correctness to be very easy to achieve, thus covering every rambling thing I say in the cloak of correctness.

Re:I like the prologue

[lennier]

"There's a newer use of the term, or a synonym that describes a broadly similar way of structuring applications that is different in many key technical ways"

In other words, there's a WRONG use of the term.

Re:I like the prologue

[dzfoo]

Actually, the author tries to limit or re-define the definitions of various technical terms and offers many personal views and points in doing so. To disagree with the author does not necessarily mean to believe that there is no ambiguity in the usage of MVC; it could very well mean that you disagree with his particular views or conclusions, his method of analysis, or maybe even with his pedantic tone or dry exposition.

His comment at the beginning of the article does not acknowledge any of these subtleties, focusing only on disagreements to his overall, generic premise, which he then states (unequivocally) must be wrong.

It's like saying "2 plus 2 is *not* 5. It cannot be because of pink or yellow. Also, I won't argue about the answer, but I will tell you that I believe it is 3. To disagree with me is to believe 2 plus 2 is 5."

So, yes, his comment in the introduction of the article reduces to merely "if you disagree with me it means you are wrong".

        -dZ.

Event Engine and Cross-Language

[Tablizer]

To get a decent cross-language GUI engine, MVC has to be tossed or changed. The code that controls the event engine should not be app-developer-modifiable, for example. They can change the event priorities perhaps, but not the event engine. In essence, the "controller" needs to be hidden away, controlled by attributes only. Specific event handlers (functions or methods) are "called" by the event engine as needed.

It can all get so large that perhaps using a database engine of some sort starts to look worth-while. It's easier to study an event priority list or stack if one can query it rather than using set/get iterators. The grouping can also be query-controlled that way. One is not stuck picking grouping by task or grouping by screen or grouping by entity. The event code (or code reference) grouping could be by whatever you feel like for a specific maintenance task. GUI engines are outgrowing objects in my opinion. Objects are fine when you have hundreds, but not bajillions.

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?

Re:Event Engine and Cross-Language

[MichaelSmith]

I work in air traffic control where we pass a lot of messages by UDP and frequently saturate our networks in the process. I get asked similar questions by new developers who have been in other industries developing various GUI applications. One thing they need to understand is that we pass a lot more data around than most applications. This works okay in C when you have a statically allocated buffer for the message. You populate it and pass a pointer to the middleware and off it goes. In OO you normally create an object and this means doing a malloc at the C level for every message.

At that point the application falls apart. It just can't allocate memory fast enough to keep up.

Re:Event Engine and Cross-Language

[Tablizer]

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.

On a small scale without a single language, perhaps. But think about the concept of a programming-language-neutral framework or protocol and you start to see problems. Why should every language need its own GUI engine? That's poor factoring. (GTK comes fairly close, but is still semi-bound to TCL and its odd conventions.)

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

What makes you say that?

Re:Event Engine and Cross-Language

[bpkiwi]

So this is just like allocating a single object, and re-using it.

That's called a singleton, a pattern that is gaining a status as an 'anti-pattern' - i.e one that should be carefully considered and probably avoided unless you know why.

Take your nice C program, with it's single global buffer, and try and run two execution threads through it in parallel. But before you do, tell me, so I don't get on a Plane that day.

Re:Event Engine and Cross-Language

[AnyoneEB]

Perhaps I am misunderstanding, but in the frameworks I have used, I do not touch the event loop. I just register events and have methods get called when they occur. In Java, the order is based on the order of registration with the event, but if the event handler does a lot of work, it should probably be in a separate thread anyway (as the next event handler cannot be called until the current one returns). I think I am just not envisioning a system with the massive number of events you seem to be describing as causing a problem because I just have not worked with a project that large. I am not sure why a GUI would have so many event handlers around that it would be hard to keep track of all of them; I would expect at most one (a few?) of each type on each widget, and even then you probably do not care about most of the events.

Re:Event Engine and Cross-Language

[MichaelSmith]

Take your nice C program, with it's single global buffer, and try and run two execution threads through it in parallel.

Threading in this system is between OS level processes with their own address spaces. At least that way the middleware is doing some work for you.

Re:Event Engine and Cross-Language

[AnyoneEB]

Okay, give each thread a buffer. Not a big deal, although something you do have to remember to do.

It sounds like the problem is not with OOP, but with garbage collected languages with insufficiently intelligent allocators/garbage collectors. The solution seems to be to either use an unsafe language which allows direct control of memory (like C++) or make the allocator smarter, perhaps by including profiling in the optimization process (otherwise the optimizer might not get clued in that it should prepare space for lots of message objects) or possibly just some sort of hinting from the programmer.

Re:Event Engine and Cross-Language

[DoubleReed]

What you say is true. But, this isn't really an OOP issue. You could shoot yourself in the foot just as effectively in C if you did this:
char* recvPacket(); /*receives the next packet, allocating memory to store it in; returns a pointer to this new memory location*/

The solution, in both C and Java is to NOT re-allocate your buffer with every packet. No matter if that buffer is a raw array or wrapped up in an object.
Take a look at java.net.DatagramSocket:
receive(DatagramPacket p);
The function takes a pointer to the buffer that the packet is to be stored in. This is exactly as it would be done in C. What is the big deal that the "buffer" in this case is represented by an object?

Re:Event Engine and Cross-Language

[MichaelSmith]

Yes but there does seem to be a tendency around OO these days to try to do away with coding almost entirely. They start with UML and hardly touch the generated code. What you get out is only suitable for some applications.

Re:Event Engine and Cross-Language

[shmlco]

"...but not the event engine. In essence, the "controller" needs to be hidden away, controlled by attributes only. Specific event handlers (functions or methods) are "called" by the event engine as needed."

The "event engine" is normally considered to be part of the framework. The bundle of specific event handlers for a given application is the real "controller".

Re:Event Engine and Cross-Language

[Tablizer]

Maybe there's a misunderstanding with regard to "event handler". In this case I meant event-handling code for a particular event or event-type-and-widget combination (button_x_pressed); and *not* the event loop and event manager itself.

Re:Event Engine and Cross-Language

[daniel_newby]

In OO you normally create an object and this means doing a malloc at the C level for every message.

Many object systems let you assign a custom allocator for high-turnover classes. It is also common practice to keep a pool (or even a pool for each core) of pre-constructed objects (reusing freed objects in MRU order), rather than constantly be tearing down objects and building them back up from scratch. It's more an issue of folks not having experience with high-throughput design, rather than a problem with OOP.

Re:Event Engine and Cross-Language

[LizardKing]

GTK comes fairly close, but is still semi-bound to TCL and its odd conventions.

Huh? The GTK API was heavily influenced by Motif and XView, as those were the toolkits that the original authors were most familiar with. The GIMP itself used Motif widgets in the earliest versions, and although there was some talk of porting the GIMP to Tk this was never undertaken. The XView influence is still apparent today as it provided a good model of how to do an object based API in C. The only other connection between GTK and Tk is the rich text widget, which was ported to GTK by Havoc Pennington for version 2.0 if I recall correctly. The widget acquired a much more object oriented API in the process, as it was the features that appealed to the GTK team, and certainly not the Tk API.

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

[Hannes2000]

I would like to see/hear/read that talk/paper. Could you perhaps provide a link? thanks

Re:Django

[Anonymous Coward]

...MVC is the only good way you can arrange 3 different tiers...

You do realize you are misusing the term tiers right?

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.

Re:Django

[Anonymous Coward]

Well, it's Model-View-Template (MVT?), then, not MVC. It's not as if MVC is the only pattern for these things, anyway; I don't know if MVT exists, but Model-View-Presenter (MVP) does, for instance.

Some people (and by that I mean the blog guy) are just whiners who don't realise that ultimately, all these things are not ends in themselves but rather just tools to facilitate getting work done.

Re:Django

[julesh]

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

Model
Template
View

Except in most people's definition of MVC, View encompasses both part of the 'View' and all of the 'Template' layers as described there. And, because there's no space left for Controller, the Controller logic ends up being implemented in the View.

Like the original author, I don't think this is necessarily a bad thing -- I've spent the last 10 years as a professional web developer using essentially the same architecture -- but it quite clearly *isn't* MVC. There's no separation between View and Controller, which is basically half the point of MVC.

Summary:

[Anonymous Coward]

"I can break the MVC pattern when coding with Django, therefore it is not an MVC framework. Even if that weren't the case, I've got some bug up my ass about programs with more-or-less static output (webpages) being described as MVC."

There, I saved you a couple minutes and a whole lot of thinking, "And? What's your point?"

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

Re:Meh

[smellotron]

"the people behind Django" = Malcom + everyone else

Re:Meh

[wezeldog]

I stand corrected. But doesn't that make the rant completely pointless? Kinda like Chip Diller screaming "Remain calm!!! All is well!!!"

Re:Meh

[Anonymous Coward]

So....what you are saying is that Django are saying 'We are not MVC', and one of the major developers is saying 'Stop saying you are MVC, you are wrong'?

Am I the only one seeing the disconnect?

Re:Meh

[smellotron]

I just take it as him fighting against the tide of awful web developers. It's an uphill battle in a hurricane with a lead weight attached to your foot, but it's The Right Thing To Do.

Re:Meh

[wezeldog]

Sounds fair enough. More power to him, then. The post was a confusing read. FWIW, there's an anti-pattern called "The Golden Hammer" where once someone has a tool in their toolbox, they try to apply to everything: I've got a hammer and everything I see is a nail. MVC being the latest and greatest hammer.

More Buzzwords From Lazy Programmers

[Anonymous Coward]

Whenever I hear people yammering on about development model framework concept engine controller view model buzzword bullshit bingo, I know that they have a difficult time of looking at a problem, understanding it, designing a program, and then keeping their nose to the grindstone until it's correctly implemented.

Programming is very simple, and it's hard. Decades of delusional wishful thinking by people trying to make it easy and complex won't change that.

And stay off my lawn.

Re:More Buzzwords From Lazy Programmers

[Anonymous Coward]

Programming is very simple, and it's hard. Decades of delusional wishful thinking by people trying to make it easy and complex won't change that.

Interesting. By that logic, I presume you also think that all 3rd party libraries, algorithms or anything else that tries to "make it easy" is also worthless?

Patterns are merely documented building blocks that can aid design, if well understood and used correctly. Not using patterns in suitable situations results in reinventing the wheel, a waste of time and money.

Re:More Buzzwords From Lazy Programmers

[springbox]

Yes, documented "patterns" can be used for design ideas, but when I hear people gushing nothing but buzzwords, I worry that there is a tendency to take it to the extreme - trying to fit problems within the parameters of a developer's favorite pattern rather than using the patterns to aid design decisions.

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

[Lars512]

And he clearly states that before he even goes into Djangos documentation and concept of MVC.

He ignores Django's own take on their differences with traditional MVC, and prefers to just bash a straw man.

Re:Wrong.

[smartr]

1+1=2 no matter what all you MVC enthusiasts think!

Re:Wrong.

[piquadratCH]

He ignores Django's own take on their differences with traditional MVC, and prefers to just bash a straw man.

I haven't had the time to read the whole piece yet, but I strongly doubt the author's intent was to ignore Django's take on MVC or even bash it. Him being a Django core developer and all...

Re:Wrong.

[julesh]

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. [...] I think you just pretty much quoted the dictionary definition of a pedant, specifically definition 2B. ...

2b. one who is unimaginative or who unduly emphasizes minutiae in the presentation or use of knowledge

I don't think so. I wouldn't say he shows a lack of imagination, and I wouldn't say that pointing out that an entire class of developers are doing something they set out to do in a fundamentally incorrect way is 'minutiae'.

Re:Wrong.

[avandesande]

One of our corporate customers demanded we switch to struts for all of our new web apps.
What a nightmare that was.

Think 'millions of tiny classes'.

What, no ads?

[kbob88]

No ads on this blog?

Really, what's the point of posting a long, pedantic, boring tirade about nothing and then submitting it to Slashdot if you can't 4) Profit?

Ugh. I only read about 2/3 of the way through. Did kdawson even bother to read halfway through? Even though I make a living using MVC frameworks, I just didn't really give a sh*t about what he was saying. Mod me redundant, but I feel better now having replied...

Can I please have those 10 minutes of my life back?

Author is Pragmatic

[Anonymous Coward]

I disagree on the author being pedantic. I believe the author is calling people who hold up "MVC!" as the one true programming model are the ones being pedantic.

Django (and similar frameworks like Rails) are NOT pure MVC. We can in some ways map the Django concepts to MVC concepts that they're similar to, but they're not the same.

I believe the author raises the question of whether "Django makes it easy, so do it!" is right. MVC purists would want to strongly separate things that it's easy and simple to do together in Django, simply for sake of a model that Django doesn't directly support. The author appears to contend that doing that is fooling yourself.

Use Django because you want to use Django, and it makes it easy to do what you want easily. Not out of some misguided view of MVC purity. If it's easy to use Django and Python to do something that you need to do, but it breaks some purity from MVC, don't worry about it.

Indeed

[cromar]

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?!

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.

Re:Indeed

[Curunir_wolf]

That's been around for years. That's why I use a browser with a "close-the-door-before-more-clowns-get-out" feature. Also known as a pop-up blocker.

Re:Indeed

[Kehvarl]

A "car"? Are we implementing this in Lisp?

Re:Indeed

[Tetsujin]

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.

Oh, great... One more car analogy added to the world of computer science. :D

Re:Indeed

[try_anything]

It matters because MVC is promoted as the orthodox and usually correct way to do user interfaces. Nobody gets fired for using MVC.

Why is this bad? Applying a pattern you don't understand is a recipe for obscure, needlessly complicated code. Many people apply MVC, and few people understand it. The results are predictable, yet we believe that programmers should keep striving to follow the MVC pattern.

I think it's time that programmers start demanding clarification every time they hear the term MVC. "MVC? That can mean a bunch of different things. What do you mean by it?" That should cut down on careless and uninformed use of the term.

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.

Re:MVC is good

[WonderPhil]

I agree, library classes for commonly-used MVC controllers are a big time-saver. A great example is in Cocoa Programming for Mac OS X (Chapter 8's use of the NSArrayController class).

Re:MVC is good

[rockmuelle]

> (so how are we supposed to go about iterations, theorists ?)

Like you, I've written a number of template engines because I didn't like the limitations of existing ones (granted, this was in the mid to late 90s, so there weren't many to choose from).

After including iterators and conditionals in two different templating engines, I decided to try to design one without these programming constructs. I had seen too many UI designers find 'clever' uses for loops and conditionals and I wanted to see if it was possible to push them just out of their reach. I was also starting to see templating engines come out that placed unnecessary limitations on developers and wanted to see if I could strike a happy medium (fully enable good developers, properly contain UI people who thought they were developers).

The solution was a combination of JSP tags and XSLT. The attributes on the tags were designed to give the UI developers control over 'stateful' list generation (e.g., generate the first 10 items, generate items 5-10, etc...). The tags themselves generated an XML stream that the UI designer transformed into markup for the target platform (this app targeted desktop browsers, Palm Pilots, and old-fasioned WML-enabled phones). While XSLT does give the UI designer basic conditionals and iteration, there wasn't enough information available in the XML stream to do much harm and most UI designers could only handle basic transforms.

The key to making this work was careful design of the tag libraries that handled the program logic. In many cases, the tag libraries were actually implemented using JSP, with JSP used as a programming tool to generate XML rather than UI tool to generate UIs.

I'm sure there are some important details that have been lost to time, but in the end, the system met the goal of separating templating and control without sacrificing development flexibility (and, most importantly, without annoying the developers or UI designers).

So, it's definitely possible to build a full-featured templating engine that limits iteration and other programming interfaces. (and trust me, I had my doubts before designing the system)

-Chris

Re:MVC is good

[Anonymous Coward]

Yeah, I've played with most "MVC" web frameworks, they all suck. Then there's real world apps where everything seems misplaced, views doing form validation, markup in database queries, pagination libraries called by the model yet generating markup and so forth.

I use the term MVC in relation to web apps all the time. I mean that the controller handles the request, loads the appropriate model and hands the data to a view where a response (markup / json etc) will be generated. There's nothing more complex to it than that, it's a tried and tested design and usually a clean way of organising a codebase.

I don't care if people are misusing the term so long as the code folks like me inevitably end up maintaining has some basic underlying design. Anything rather than the amateur spaghetti-like projects I've inheritied in the past.

Re:MVC is good

[Anonymous Coward]

You seem confused.

MVC is a design pattern. Libraries such as Struts, Spring, etc are frameworks that implement an MVC design pattern.

If you're programing websites, or any other application, using an MVC design pattern you can save yourself the trouble of developing the MVC parts of the application by using a library that has already been coded.

I have written my own framework that I use for my sites. Struts was more popular but I found it cumbersome and slow compared to doing it myself.

If I wanted to, even within my own framework I can violate the MVC principles but I don't.

A framework is not a meta-language and it dosn't site on top of your application. It's exactly what the name implies. The structural components. Your application sits on top of the framework, not the other way around.

Re:MVC is good

[jrumney]

I used to work for a company that made an MVC framework of sorts. We had conditionals fairly early on, but did without iterators in the view for a long time. Our own developers didn't miss them - there were better ways of dealing with sets of data than iterating through them - but the customers could not get out of the procedural programmer mindset and eventually we gave in and added iterators.

Re:MVC is good

[bytesex]

Sorry, but the thought of XSLT iterators and conditionals makes me shiver a bit. Nice if it works for you, though.

Re:MVC is good

[julesh]

The solution was a combination of JSP tags and XSLT. The attributes on the tags were designed to give the UI developers control over 'stateful' list generation (e.g., generate the first 10 items, generate items 5-10, etc...). The tags themselves generated an XML stream that the UI designer transformed into markup for the target platform (this app targeted desktop browsers, Palm Pilots, and old-fasioned WML-enabled phones). While XSLT does give the UI designer basic conditionals and iteration, there wasn't enough information available in the XML stream to do much harm and most UI designers could only handle basic transforms.

Hmm. That sounds rather like the "when-I-have-time-for-it" idea that's been floating around my head for the last two years...

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

[interval1066]

I did some work under an absolute nutcase that insisted I use MVC while writing a wikimedia extension module. I don't get mvc implemented in php to begin with, but when I started getting the idea that he used the pattern for everything he did, I started getting the idea that I worked for a nutcase. Its a useful pattern for sure, but expecting a wrench to fix a problem that requires a hammer, or a screw driver, is a problem, imo.

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:Praise the Lord!

[booch]

Actually, one of the common issues that beginning Rails developers have is to put too much business logic in the controller. There's even a name for the theory that almost all logic should be in the model: "skinny controller, fat model".

I actually had a bit of a hard time wrapping my head around the web-style MVC, because it doesn't follow the traditional GUI form of MVC. (Mainly because the model doesn't send updates directly to the view.) But the "best practices" that Rails suggest actually do make sense as MVC. And the more you stick with those best practice separations, the easier it is to work with your code.

I'm glad I'm not the only one

[MarkusQ]

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, consider the fact that "Real" with the little swirly (as applied to cheese) is a trademark, not an adjective--the American Dairy Association could market tofu as "Real(tm) Cheese" if they wanted to.

The problem comes in when you start assuming that things that were true of the original use of the word are still true under the new use. Web-frameworks are MVC in exactly the sense that partially hydrogenated vegetable oil is cheese.

--MarkusQ

Re:I'm glad I'm not the only one

[Xest]

They only harm themselves too. I find most PHP frameworks are much more difficult to learn than they really should be simply because they muddy the waters so much with regards to what is in and where each of the components of MVC sits in their particular implementation.

We've got bigger problems.

[wilder_card]

Considering that most developers using "object-oriented" languages don't seem to understand object-oriented programming, their failure to understand a particular pattern is not at all surprising. You can take a functional design, wrap it in an object, and say you're doing object-oriented programming, but that doesn't make it right.

Re:We've got bigger problems.

[Anonymous Coward]

God, don't I know it, where I work everyone seems to do this. Oh, I have a bunch of functions that are related, lets put them all in a class together.

Sorry, if your objects contain only functions and no attributes, they are not objects, just write functions FGS!

Re:We've got bigger problems.

[Weedlekin]

"if your objects contain only functions and no attributes, they are not objects"

The people who invented the term "Object Oriented Programming" together with much of the other terminology we use today while designing and implementing Smalltalk would disagree with you.

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:HWND Duck;

[mikiN]

ObLink: this

No chickens were harmed during the writing of this post (or the linked-to article, I suppose), nor any turkeys.

Q: Specially designed oblong freight container for Santa's use on his desert travels?
A: A CamelCase

Bulshytt

[0xdeadbeef]

In web applications the generated HTML is the view. The template code and javascript are the controller. The model is anything and everything providing input to the template.

Just because something is painful or stupid doesn't make it any less MVC.

(What would break his precious pattern definition is putting data-mutating logic in the template, like every php application ever written. Which I guess is the only real value of MVC - it's a simple rule of thumb to prevent noobs from hurting themselves.)

Re:Bulshytt

[julesh]

The template code and javascript are the controller. [...] What would break his precious pattern definition is putting data-mutating logic in the template, like every php application ever written. ...? In the MVC pattern, data-mutating logic goes in the controller. You just said that is the template code, but then you say that it shouldn't be in the template code. You're making no sense.

Which I guess is the only real value of MVC - it's a simple rule of thumb to prevent noobs from hurting themselves.

And provides a basic, easy to understand design for a common requirement of GUI applications: having two windows that show different views of the same data, which update synchronously. That's the part that's almost always missed in web applications, which is at least part of the author's point. MVC does have a purpose, but it's almost useless in the web context because you can't actually implement it (as it requires a call back from the model to the view, which would typically be javascript running on the client, and therefore can't accept such a call back).

The title should be

[Anonymous Coward]

Model-View-Controller -- unheard of and not used ...
at least for most hobby or PHP programmers ;-)

Welcome to the club, old timer

[plopez]

This is the same rant that happens every time a good idea gets corrupted in IT by marketroids or half bright monkeys:

OOP, relational databases, software libre (which isn't the same as open source BTW, and I prefer the term "libre" since the word "free" is overloaded and hence misunderstood in the English language), distributed computing, WWW, XML or whatever.

One of the many reasons I have chosen a new career path.

Breaking the MS WIndows monopoly

[Latent Heat]

The issue I see MVC addressing is the transition from Model-View-Controller to Model-View (or Document-View) to just plain View, or widget, the MS Windows default state of affairs.

The temptation is to place all of the functionality into one entity -- a widget, an ActiveX control. Model, GUI presentation logic, how it interacts with everything else, all this is packaged into a unitary entity. Great for lock-in to a vendor or OS or platform.

In my thinking, controllers serve a useful purpose to break free of vendor-GUI lock-in. The model, of course, contains the data and logic in a GUI-agnostic way. But the problem is that "model" may only constitute 10 percent of your program -- the bulk of code in a GUI app deals with GUI concerns of one kind or another.

The controller, on the other hand, contains GUI logic, but in a platform-agnostic way. It is the view and the view alone that has the lock-in to Windows or Java Swing or whatever the GUI-du-jour. Separating view and controller, I believe, is the way to get more of your application not tied into whatever GUI you are using.

terrible article

[vingilot]

what a whiner.

MVC was/should be more than this

[MarkusQ]

Yes, but there is (or at least was) more to it than that.

The model is/was supposed to house all of the details about how things interact, without regard to how you want to look at them (views) or mess with them (controllers).

Nowadays, models are more times than not just a sort of glorified persistence layer, describing the data in static terms and lacking the juicy details of how the data dances.

--MarkusQ

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

Re:Glossary?

[Xest]

Most of these concepts are over a decade old, so I'm not sure where you've been but it suggests you've not really learnt anything new in that last 10 years. You could be forgiven over templates as they're something you could get by without ever needing to know if you right software that doesn't need them but patterns? you've never heard of design patterns?

I'd recommend getting some software development education as it sounds like whilst you may know how to program, you don't know even the basics of software engineering. For information what patterns are, see here:

http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

I understand that if you've used only C and assembly and have barely touched C++ you probably don't even really have an understanding of OOP (object oriented programming) which is probably part the problem, this would be a good starting point- learn a language where OOP is enforced, Java perhaps?

Re:Glossary?

[Stiletto]

Looks like we're simply talking about abstraction, software reuse, and components, just painted over with a little formal language. You're right--nothing new. I've just never heard anyone in the industry talk like that. Nobody I know sits in their cube talking about software design theory. Nice to know this class of concepts has a name, I guess.

Re:Glossary?

[Xest]

You probably wont hear many people talk about patterns. It's rare that a programmer says "Oh we need a factory pattern for this", they'll usually just go ahead and implement using a factory pattern because that's what design patterns are about- the fact that many parts of programs actually follow a small set of patterns to get jobs done and these patterns show their head over and over.

If you have been doing a decent amount of OO programming then you probably have been using some of the common patterns without ever even realising it. This could explain why you've missed the term because it's just so common no one really talks about it, they just do it although if you're involved in application architecture at the higher level- putting together UML diagrams and so forth you are more likely to come across these terms.

Templates in the context of this article just refer to the idea of website templates, i.e. the basic layout of the site or site components where the content is filled in by different parts of the application (i.e. different layers such as the controller fed by the model). Of course, the idea extends beyond the web, normal applications can use UI templates for example or even the more obvious document templates but I don't imagine you do much UI or web stuff if you're using C and assembly mostly? Presumably if you use those languages it's lower level, perhaps embedded stuff you do?

Re:Glossary?

[Stiletto]

All embedded. C++ has made its way into embedded devices but often only to glue on libraries that expose C++ interfaces.

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

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

[owlstead]

I was at a rather fine presentation at a Java user conference once. It looked like a demonstration of Eclipse refactoring: everything was refactored into patterns. The guy new all the right key bindings and everything moved blindingly fast. Within half an hour fields were moved/introduced, factory methods and classes created, variables renamed: it was rather fun and impressive to look at.

Then - in the second half - he explained in depth that he just made a complete mess of a perfectly fine and simple *working* application by introducing all these patterns. Funny and a lesson people won't forget easily.

Design Patterns - The Book

[Mybrid]

I don't really see why discussing MVC is as all that and a bag of chips as the author contends. I commonly use the concept of MVC with respect to Django and when I do I always reference this book:

Design Patterns, Elements of Resuable Object-Oriented Code

Using the definitions as described in this book Django easily fits in the MVC design pattern.

People I work with "get it" and I've not encountered and confusion alluded too by the author when using the term as defined by the aforementioned book.

Language is always evolving and that is how non-technical words end up with multiple variations in the common language dictionary. I see no reason why technological terms should be excluded from this "language pattern". There is no notion that technogical terms have to stick to some "original definition". The book above provides a working definition that is common and clear.

Re:Design Patterns - The Book

[julesh]

I commonly use the concept of MVC with respect to Django and when I do I always reference [GoF]. Using the definitions as described in this book Django easily fits in the MVC design pattern.

Except it doesn't. According to the definition in that book, View is an Observer of the Model. That relationship is not implemented in Django, and is in fact extraordinarily difficult to implement across a web interface (because it requires the model to be able to call back to the view, which is typically a combination of javascript and html residing on the client computer).

Re:Design Patterns - The Book

[Mybrid]

Hi!

From my perspective over the years I've used the MVC as a design pattern definition and never experienced the communication problems listed by the author.

With respect to "Observer" I would respectfully disagree.

Most notabley, imagine if you used an application indirectly by taking screenshots. Of course the "model" in this case would not be able to "update" the screenshot, but it would be able to update the application that was screenshot.

Web applications are really screenshots. They are not interactive in the sense of a desktop GUI.

When I as a grad student at Berkeley the question was asked can MVC be applied to such asynchronous applications as email and HTML. The answer was "Yes" if the *user* understood that they were dealing with disconnected or asynchronous views.

Take something like Subversion where a GUI connected to Subversion server can be MVC with respect to the Observer as required. Then I disconnect my laptop from the network. Is the design still MVC? The server models can no longer update the view until the laptop plugs back in?

To wit, the defintion of MVC has evolved to include applications where at times the view is disconnected and in the case of the web, all the time disconnected until the view checks in. That still doesn't mean the underlying design has changed.

Again, I've never experienced the confusion of the original post. Not ever. Which says to me that there must be a rather large community that can use the evolved definition of MVC to incorporate asynchronous and synchronous applications.

Presumption of Correctness

[Software Geek]

There is a widespread presumption that all good GUIs are MVC based. So, to get approval for a design you have to dress it up in MVC terminology, whether that makes any sense or not. After twenty years of this, the terms no longer even mean anything, since so many wildly differing things have been labeled MVC. Time has transformed an excellent pattern of limited applicability into a useless time waster that must be applied to everything.

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

Re:Have you every noticed?

[julesh]

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

I keep hearing this assertion, but I've never seen it demonstrated. Certainly, having written a substantial chunk of a popular web application framework, it doesn't seem to be a complaint that could be levelled at the specific author of this article.

Re:Have you every noticed?

[tiagobrandes]

yeah that's usually true, but this one guy was responsible for completely refactoring Django's object-relational mapper he can probably code himself out of a nuclear war if you ask me

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.

Nobody mentioned Web Dynpro yet?

[hotdog.sk]

When we're talking about misusing the term MVC, SAP's Web Dynpro "MVC" must be mentioned as of the prominent cases:

• View is subclass of controller (it is actually called View Controller)
• All controllers except View Controller can raise events (I still have no idea what they can be used for)
• Component Controller (the one that should stand for "C") does not have control about what is displayed on screen. Instead, view controller can fire navigation plug, which must be linked to another view
• Models are generaly meant as wrappers around ABAP functions at R/3 backend. You can create them around POJOs, but updating the model after you modify the class is bit of voodoo.

After week of use, I mentally mapped their terms Model, View, Controller to Stick, Carrot, Snowman, and it doesn't confuse me since.

Worse on the web.

[Xest]

I find this is more of a problem in web development than in classic application development. The problem stems from the fact that anyone can do HTML and many web "developers" have moved from that to languages like PHP that don't teach or enforce good use of OOP, type safety and other important concepts. It's not bad that PHP doesn't do that in itself, because it's still a good language for knowledgable, sensible programmers but that's not a large part of it's userbase unfortunately.

The problem is demonstrated strongly with the likes of HTML5, this goes against everything good that has been done in XHTML to push separation of concerns because doing so is important for an accessible, consistent, well built web. I don't agree entirely with some of the design decision of the newer releases of XHTML- phasing out tables seems to be one of the worst ideas but it's still a whole lot better than mixing up content, presentation and so on into one big single mess.

The two sides are basically this, if we allow lazier development we end up with a much less accessible, much less portable web but we get more content because anyone can publish even if what they publish is badly developed. The alternative is we push for much stricter web development that requires a lot more skill and discipline to do properly and results in a much more portable, accessible web but has the downside of less people publishing because some wont want to make the effort.

It's a hard choice for sure, personally I'm on the side of forcing people to do it properly if they want to do it at all, but I do understand that may isolate people who do benefit the web with useful (albeit poorly implemented) sites and content.

The view can contain logic related to the view...

[Anonymous Coward]

People saying that the view should have zero logic in it simply don't get it. The view should have no business logic, but it doesn't mean the view cannot have logic at all.

And it's not "one or the other". Take data validation for example: it is perfectly valid (and very often recommended, for bandwith saving purpose and responsivness purposes, etc.) to do some data validation on the client side in a Web browser. Does this means that if you do that you don't do validation on the server side anymore? Of course not...

Regarding Java as being "nonsense" for the Web: the biggest websites of this planet (GMail, FedEx, eBay) are backed by Java webservers. And websites that don't scale, once too succesful, are rewritten in Java...

You're assuming

[samael]

...that MVS is _right_ and leaving that pattern is _wrong_.

Which is not always correct.

Re:You're assuming

[truthsearch]

No, I'm not assuming MVC is always the right way to go. I could have phrased my comment differently to make that more clear.

My point is that some developers think they're using the MVC design pattern because their framework fosters it, when in reality they aren't.

Re:You're assuming

[samael]

Aaah, I assumed that the "will also let you hang yourself" bit meant "If you stray from the MVC path then you're doomed". Sorry!

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.

Model->View callbacks

[DragonWriter]

MVC does have a purpose, but it's almost useless in the web context because you can't actually implement it (as it requires a call back from the model to the view, which would typically be javascript running on the client, and therefore can't accept such a call back).

If its JS, rather than just HTML, it could certainly poll a message queue, which (given suitable tolerance for latency) would allow it to accept and respond to callbacks, albeit asynchronously rather than synchronously.