Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Model-View-Controller — Misunderstood and Misused

kdawson posted more than 5 years ago | from the more-mvc-than-thou dept.

Programming 221

paradox1x writes "Malcolm Tredinnick shares a terrific rant against the misunderstanding and misuse of the Model-View-Controller design pattern. In particular he takes issue with the notion that Django should be considered an MVC framework. He says that 'It's as valid as saying it's a "circus support mechanism," since the statement is both true, in some contexts, and false in others (you can definitely use Django-based code to help run your circus; stop looking so skeptical).' I'm not sure I agree with the entire piece, but it is a very good read." We recently discussed another look at the bending and stretching of MVC patterns in the world of Web development.

Sorry! There are no comments related to the filter you selected.

Model View . .. (-1, Troll)

Anonymous Coward | more than 5 years ago | (#25965333)

... my frist psot!!!

Re:Model View . .. (3, Funny)

Anonymous Coward | more than 5 years ago | (#25965501)

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

Pedantry (5, Insightful)

Anonymous Coward | more than 5 years ago | (#25965345)

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!

Indeed (1)

cromar (1103585) | more than 5 years ago | (#25966037)

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 (2, Funny)

Tetsujin (103070) | more than 5 years ago | (#25967187)

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 (2, Funny)

jvkjvk (102057) | more than 5 years ago | (#25967679)

Perhaps it's a new transport mechanism, designed to compress, transport and unpack data objects(we can call them "clowns"). The cool thing would be that you get more data out during the unpack stage than you'd ever think would fit in so small a transport (we could call that a "car"!).

There you go.

Web Frameworks (4, Insightful)

truthsearch (249536) | more than 5 years ago | (#25965375)

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 (3, Interesting)

CodeBuster (516420) | more than 5 years ago | (#25966167)

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 (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25968667)

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 (-1, Troll)

Anonymous Coward | more than 5 years ago | (#25966965)

Your framework doesn't frame anything and it doesn't work. It sucks putrescent donkey cock, and the only reason you don't is that donkeys aren't that easy.

Author is Pedantic (5, Insightful)

iluvcapra (782887) | more than 5 years ago | (#25965445)

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 (1, Insightful)

Foofoobar (318279) | more than 5 years ago | (#25965615)

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 [sourceforge.net] as a very simple example.

Re:Author is Pedantic (2, Insightful)

plover (150551) | more than 5 years ago | (#25965843)

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 (3, Insightful)

KDR_11k (778916) | more than 5 years ago | (#25965959)

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 (2, Informative)

lorenzo.boccaccia (1263310) | more than 5 years ago | (#25966597)

mmmmm, I've mixed feelings on this: for one, view could delegate validation to the controller, or better, view could request controller to check if the display data is consistent with the model constraint, so the controller should delegate validation to the model. so validation in MVC could happen almost everywhere (view constraints, business rules, model constraints) which is still an unresolved debate - every layer has it's motivations.

otho, 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(tm): without calling rich client into the fray, views as simple as static html pages could posts, could transform your inputs using asterisks in password field, could have link which are active components and so on.

and could blink!(/duck)

Maybe MVC as a pattern starts to get old as the applications gains more and more distance from the model of the gang of four times: there centralization and dumb client was more a necessity than a choice, and as400 terminals didn't allowed much logic on the user side.

Re:Author is Pedantic (3, Interesting)

Chabil Ha' (875116) | more than 5 years ago | (#25967047)

...the idea that the view should never contain logic at all is quite dogmatic and as such doesn't work well on the real world...

I think that's what the OP is trying to say when he comments that 'MVC is a pattern'. Patterns help solve particular problems, but when following the pattern in the most purist of the sense doesn't solve the problem (or gasp! make it bigger!) then being 'pure' doesn't make sense.

Take AlertBox [useit.com] . I think there some gems in his usability suggestions, but if you follow his guidance to the 't', you end up with a boring and un-user-friendly site like his.

Re:Author is Pedantic (1)

agbinfo (186523) | more than 5 years ago | (#25967955)

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 (0)

Hognoxious (631665) | more than 5 years ago | (#25967189)

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 (1)

B47h0ry'5 CuR53 (639887) | more than 5 years ago | (#25966331)

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 (1)

Foofoobar (318279) | more than 5 years ago | (#25966715)

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 (1)

Foofoobar (318279) | more than 5 years ago | (#25966921)

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 (1)

imbaczek (690596) | more than 5 years ago | (#25966939)

The view should do ZERO processing.

practicality beats purity.

Re:Author is Pedantic (1)

Kent Recal (714863) | more than 5 years ago | (#25968661)

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 (1)

mini me (132455) | more than 5 years ago | (#25968037)

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 (1)

Foofoobar (318279) | more than 5 years ago | (#25968825)

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 (3, Insightful)

LaskoVortex (1153471) | more than 5 years ago | (#25965653)

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 (1)

Shados (741919) | more than 5 years ago | (#25966159)

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 (1)

Mr. Slippery (47854) | more than 5 years ago | (#25967691)

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 (3, Interesting)

Shados (741919) | more than 5 years ago | (#25968257)

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.

Wrong. (3, Insightful)

Qbertino (265505) | more than 5 years ago | (#25965819)

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. (5, Funny)

plover (150551) | more than 5 years ago | (#25966197)

Author is Pedantic

No he isn't. He critisizes the incorrect use and application of the term MVC and the misconception and the pointless enforcement of a wrong concept of MVC in places where it is often more than pointless to do so. Like in most modern web application scenarious.

I think you just pretty much quoted the dictionary definition of a pedant [merriam-webster.com] , specifically definition 2B.

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

Re:Wrong. (1)

smartr (1035324) | more than 5 years ago | (#25967347)

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

Re:Wrong. (1)

Lars512 (957723) | more than 5 years ago | (#25966675)

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

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

Re:Wrong. (1)

piquadratCH (749309) | more than 5 years ago | (#25967599)

He ignores Django's own take [djangoproject.com] 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 [djangopeople.net] and all...

Re:Author is Pedantic (1)

vux984 (928602) | more than 5 years ago | (#25965847)

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 (2, Insightful)

KDR_11k (778916) | more than 5 years ago | (#25966051)

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 (1)

vux984 (928602) | more than 5 years ago | (#25966255)

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 (1)

Dragonslicer (991472) | more than 5 years ago | (#25966571)

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 (1)

Fulcrum of Evil (560260) | more than 5 years ago | (#25966899)

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 (1)

Jeff Hornby (211519) | more than 5 years ago | (#25966601)

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 (1)

Todd Knarr (15451) | more than 5 years ago | (#25966525)

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 (1)

MichaelSmith (789609) | more than 5 years ago | (#25966831)

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 (1)

vux984 (928602) | more than 5 years ago | (#25967481)

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 (1)

shutdown -p now (807394) | more than 5 years ago | (#25965961)

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.

Author is Pragmatic (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25966025)

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.

Re:Author is Pedantic (2, Informative)

Vornzog (409419) | more than 5 years ago | (#25966233)

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 [djangoproject.com] :

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 (1)

destiney (149922) | more than 5 years ago | (#25967295)

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 (1)

Daimaou (97573) | more than 5 years ago | (#25968475)

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.

wait a second! (4, Funny)

girlintraining (1395911) | more than 5 years ago | (#25965447)

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! (5, Funny)

mmkkbb (816035) | more than 5 years ago | (#25965585)

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

Re:wait a second! (1)

Evanisincontrol (830057) | more than 5 years ago | (#25965685)

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! (4, Funny)

JCSoRocks (1142053) | more than 5 years ago | (#25965965)

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

Re:wait a second! (1)

fbjon (692006) | more than 5 years ago | (#25966941)

The Universe is the only real algorithm anyway.

Re:wait a second! (3, Funny)

Hillgiant (916436) | more than 5 years ago | (#25966813)

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

Re:wait a second! (1)

Kent Recal (714863) | more than 5 years ago | (#25968727)

Welcome to the real world [is.gd] , I guess.

Re:wait a second! (1)

dollargonzo (519030) | more than 5 years ago | (#25966135)

I think you meant Don Knuth

huh? (5, Funny)

larry bagina (561269) | more than 5 years ago | (#25965493)

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

Re:huh? (0, Flamebait)

Smidge207 (1278042) | more than 5 years ago | (#25965895)

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

You aren't familar with Roland Piquepaille [primidi.com] are you?

=Smidge=

Re:huh? (2, Insightful)

daveime (1253762) | more than 5 years ago | (#25965937)

About 27 nanoseconds after the first blogging software was created.

I like the prologue (4, Funny)

mattdm (1931) | more than 5 years ago | (#25965513)

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 (0)

Anonymous Coward | more than 5 years ago | (#25966485)

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 (1)

colmore (56499) | more than 5 years ago | (#25968009)

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 (1)

Bill, Shooter of Bul (629286) | more than 5 years ago | (#25968593)

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 (0)

Anonymous Coward | more than 5 years ago | (#25967435)

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.

Event Engine and Cross-Language (0)

Tablizer (95088) | more than 5 years ago | (#25965563)

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 (2, Interesting)

AnyoneEB (574727) | more than 5 years ago | (#25965939)

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 (1)

MichaelSmith (789609) | more than 5 years ago | (#25967063)

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.

Django (5, Insightful)

styrotech (136124) | more than 5 years ago | (#25965629)

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 (4, Informative)

Fallingcow (213461) | more than 5 years ago | (#25967405)

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

Model
Template
View

Re:Django (2, Informative)

xfour (1422499) | more than 5 years ago | (#25967787)

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 (1)

Hannes2000 (1113397) | more than 5 years ago | (#25967989)

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

Re:Django (0)

Anonymous Coward | more than 5 years ago | (#25968071)

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

You do realize you are misusing the term tiers right?

Re:Django (2, Informative)

Evdawg (872579) | more than 5 years ago | (#25968229)

This is correct. The issue is in fact addressed in Django's official FAQ [djangoproject.com] .

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.

Summary: (0)

Anonymous Coward | more than 5 years ago | (#25965729)

"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 (2, Informative)

wezeldog (982156) | more than 5 years ago | (#25965747)

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/ [djangobook.com]
Here's another:

Taken together, these pieces loosely follow the Model-View-Controller (MVC) design pattern.

They don't seem to be too hung up on design pattern purity. Maybe it is different in IRC or the forums.

Re:Meh (3, Informative)

omuls are tasty (1321759) | more than 5 years ago | (#25966103)

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

mod 0p (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25965783)

forwards we must it. Do notu share GAY NIGGERS FROM

More Buzzwords From Lazy Programmers (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25965805)

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 (0)

Anonymous Coward | more than 5 years ago | (#25966851)

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.

What, no ads? (1, Funny)

kbob88 (951258) | more than 5 years ago | (#25965861)

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?

MVC is good (3, Insightful)

bytesex (112972) | more than 5 years ago | (#25966151)

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 (1)

WonderPhil (1121695) | more than 5 years ago | (#25966699)

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 (1)

rockmuelle (575982) | more than 5 years ago | (#25967471)

> (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 (0)

Anonymous Coward | more than 5 years ago | (#25967703)

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 (0)

Anonymous Coward | more than 5 years ago | (#25968239)

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.

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

interval1066 (668936) | more than 5 years ago | (#25966161)

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.

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

CodeBuster (516420) | more than 5 years ago | (#25966487)

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.

Praise the Lord! (2)

Qbertino (265505) | more than 5 years ago | (#25966181)

This guy and his essay on the issue at hand is a breath of fresh air in a ongoing onslaught of web-developement misconceptions that increased tenfold ever since countless Java freaks joined the fray with the hype called Ruby on Rails.

I beg all people to read it and read it well. Please.

May I quote one part:
In the MVC pattern, the Model is the application object. It contains all the presentation-agnostic, data-centric logic, which is often labelled "the business logic".

Yes. Say it again. Halleluja!

I'm glad I'm not the only one (1)

MarkusQ (450076) | more than 5 years ago | (#25966211)

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

Breaking the MS WIndows monopoly (1)

Latent Heat (558884) | more than 5 years ago | (#25967769)

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.

We've got bigger problems. (1)

wilder_card (774631) | more than 5 years ago | (#25966453)

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

Anonymous Coward | more than 5 years ago | (#25966859)

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!

HWND Duck; (2, Funny)

mikiN (75494) | more than 5 years ago | (#25966849)

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; (1)

mikiN (75494) | more than 5 years ago | (#25967105)

ObLink: this [blogspot.com]

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 (1, Insightful)

0xdeadbeef (28836) | more than 5 years ago | (#25966891)

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 (1)

(TK2)Dessimat0r (669581) | more than 5 years ago | (#25968701)

Nope, the entire thing is the view. The model is the business logic that goes behind the entire site, the bit that still works when the view is taken away. No way are template code and Javascript the controller. The controller glues the view to the model, transforming the information. It is not a discrete entity. Back to school with you.

The title should be (0)

Anonymous Coward | more than 5 years ago | (#25966959)

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

Welcome to the club, old timer (1)

plopez (54068) | more than 5 years ago | (#25967357)

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.

terrible article (1)

vingilot (218702) | more than 5 years ago | (#25968607)

what a whiner.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?