MVC and web apps: oil and water

Roll back the clock by two years. That’s before AJAX, before Web 2.0, before Rails. Where were we then? Well pondering whether MVC was really such a good idea after all. Continuing from there…

What is MVC?

For a long answer, the best I’ve seen (for web heads) is Jeff’s analysis here. There more to be found via Wikipedia and yet more on the old C2 wiki.

A short answer, for web applications (with a PHP slant), is probably – a way to organise code based around the following ideas;

  • Model – those functions that wrap calls to your db
  • View – the templates / scripts that output HTML
  • Controller – the stuff that examines variables like $_GET and $_POST and works out what to do next

What’s important to remember is there’s no absolute definition of MVC and there are many grey areas for interpretation and yet more when it comes to using it online. That in itself means, if you’re building a framework, you just need to put the words “Model”, “View” and “Controller” in there somewhere and you’re probably as “right” as anyone else. A while back John Lim dared to ask Is MVC over-designed crap?, I suspect coming for the gut instinct of an experienced programmer. In a later update he wryly commented;

is MVC overdesigned crap? Well i was wrong about overdesign — it’s actually underdesigned. Is it crap? That remains to be seen.

Why MVC?

So why did MVC become a common pattern (or at least a common term) for web applications, bearing in mind it originally evolved for to help building desktop GUIs?

As far as I know it first showed in Sun’s Model 2 architecture somewhere around 1999(?) then crystallized into a specific (and popular) implementation: struts, around Y2K. From there, put bluntly, it seems to have become a self perpetuating mantra or tech lemming syndrome. It’s hard to find justifications of “why MVC” vs. any given alternatives, other than it’s not Model 1 (vanilla ASP / PHP would be regarded as Model 1). Most frameworks I see today advertise MVC without any indication of why they’re using it.

And lets face it: MVC sounds impressive (and intimidating) to people no in the know. What do we do when we see a term we haven’t come across before – search and find many other people saying “Yes MVC”.

So have we asked enough questions or have we just jumped on a collective bandwagon? Jeff in fact states the bandwagon factor clearly in the value of MVC – that there must be “something” in MVC because of demand for struts developers.

To me there’s a further red flag waving in that the classic hallmark of MVC in deskop apps where multiple, unrelated views that automatically updated given any change in the model (Jeff describes this nicely as the active model). Unfortunately, in traditional (as in non-AJAX) web apps, a view corresponds to a single web page response to a browser and within request-response protocol like HTTP, there’s no room for the server to instruct somer other browser window you have open that it also needs updating: web servers don’t contact you – you contact them. The hallmark of MVC doesn’t work on the web unless you hack some kind of client side refresh mechanism for check for updates. Could this be hint that MVC separation is not a best fit?

What I suspect is if we ask “Why was MVC chosen over [insert pattern here]?” loudly enough, the response will just be shuffling of feet and the occasional “Why not?”. Perhaps the guys that rolled “Model 2″ might be frank – “We needed a pattern our (AWT / Swing) developer community could relate to and MVC was near enough. It wasn’t meant to be taken this seriously.”

All this is not to say MVC sucks and that you can’t built web apps with it. Just that I think we’re talking about square pegs and round holes. The real question is there a better way?

Alternatives

ASP.NET and JSF have both tried to bring Event Driven Programming to the server side, to mixed reactions. Given that we have enough miles on the ASP.NET clock now, the impression I get is experienced web developers are wary of ASP.NET because it’s “too smart” – the learning curve to mastery is significant and there’s perhaps too much clever stuff being done transparently in those web controls. ASP.NET is probably more pleasing to those coming from a VB6 background. Whether or not event driven programming is actually a competing paradigm to MVC is debatable but it’s probably fair to say it demotes the controller to a less significant part.

Meanwhile Coldfusion developers are still getting on fine with fusebox. ‘Nuff said.

Personally I don’t have anything specific to offer but rather more thoughts about how we got to MVC and specific issues with implementations. And I’m not ruling out MVC here, just questioning how it’s commonly being used.

Make Resources First Class

One issue I have with struts and derivatives is they promote actions as first class objects ( in Rails actions are class methods but I would still argue “first class”).

HTTP only has two actions (at least that are actually being used) – GET and POST – retrieve it or update it. At this point it’s worth reading Why Do Web Server APIs Suck So Much?.

To me a direct consequence of promoting actions as first class objects is we end up with people putting verbs in URLs like “http://example.com/item/1/delete”, which in turn leads problems like this and implies tight coupling (between client and server) and RPC. GET is clearly labelled as “safe / read only” while putting a verb in a URL implies something is going to be done (which may or may not be safe);

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

In a way it’s amazing that it’s taken until 2005 for us to collectively realize this stuff matters.

The other downside of putting actions first is I think it leads of counter-intuitive code, to all but hard core frameworkers. To most people the web means documents, pages, images, movies – stuff that it tangible and can be downloaded and stored offline – resources in other words.

So let’s make resources first class objects and have framework APIs reflect that. This is what REST is trying to tell us.

This might just mean finding smarter ways to write view centric code, emphasizing DRY while avoiding spaghetti – consider the “article.php” in this URL.

Alternatively it might mean we spend more time working on classes like;

class Joke extends Resource {
    function GET($Params) {
        # Return / display a joke
    }
    
    function POST($Params) {
        # Create or update a joke
    }
    
    function DELETE($Id) {
        # Delete a joke
    }
}

class Jokes extends Resources {
    function GET($Conditions = array()) {
        # Return / display a list of jokes
    }
}

Alternatively, for a really challenging point of view about putting resources first, you have to look at Wheat ( a prototype which sadly seems to have fizzled out, I would guess because the project objectives are at very high altitude );

Every object has a URI

And from the Wheat intro here;

I’ve been asked why does this warrant a new language (somehow no one seems to care about the new environment…). Here is one of my more wordy replies:

“There is no language today in which objects are conceived as the persistent, globally accessible entities that web programming today attempts to model. Web programming is sufficiently different from desktop and server application programming to warrant a new model: When building for those environments we expect programs to be started at a point in time, read the user’s data from some data store into the heap, process it, possibly interacting with the user, write it back and then quit. Heap based objects, or more generally, languages where the unit of operation is on ephemeral, memory based data, works perfectly for applications. When we think of web programming, we are trying to create a view where the user’s content is ever present, ever live, and widely accessible. Rather than build this world view up on top of an memory based foundation, Wheat has an object and language model that can directly support this style of programming.”

Scary! What if we really are all barking up the wrong tree? Perhaps there’s a relationship here to interest in closures.

Side note: would argue the content classes and objects in eZ Publish fit somewhere into the above description, being persisted in the DB.

AJAX and Forms

Imagine for a moment that AJAX really does turn out to be all it’s made out to be; that everyone has a browser that supports it, that they’ve left Javascript turned on etc. etc. Here we’d have an environment where MVC really could be applied correctly – something very close to the original fat clients MVC was intended for, but powered by Javascript, DOM and XMLHttpRequest.

So where would that leave the server-side? It pushes it down at least one layer, to become “back end” – the logical equivalent to databases in web apps today. You just want it to serve and accept updates to resources in a stateless manner – GET and POST.

If still you’re applying MVC on the server side, you’re probably keeping it as simple as possible, preferring to use strategy over framework. You’ve still got business logic on the server but controlling logic (including execution of workflows) has moved to the AJAX client. The server side has become a service layer I guess.

Side note:what activegrid seems to be doing with BPEL seems to be heading in this sort of direction, although it’s still server side technology. Within the activegrid “mindset”, PHP scripts are relegated (perhaps rightly so) to being “services”, just pumping text.

There’s also good chance you’re no longer generating forms on the server side but doing it dynamically with Javascript on the client side. Failing that, perhaps you’re using “standalone” form pages which are well seperated from your other resources. A “wizard” form, of multiple pages, no longer requires hidden input fields or otherwise but lives in the browsers memory as Javascript objects until the form is completed. If the elimination of form generation from the server side sounds far fetched, consider the precedent search box in Firefox (top right) – personally it’s been a long time since I looked at the search form on Googles home page.

What I’m really trying to say here is I think the desire for MVC on the server side is a result of obsessions with forms, limitations of Javascript, the desire to compete with desktop apps and that form method=”DELETE” never happened (so it was necessary to bundle this as another action via POST the action). You’ve got a button on your form called “Add To Cart” so you clearly want an AddToCartAction somewhere. With AJAX perfected, we’ll presumably be implementing our shopping carts purely client side, only getting back to the server again somewhere around the “Checkout” time.

RUD not CRUD

Perhaps another hangover from trying to put desktops online is talking about CRUD – four operations: create, retrieve, update, delete. With HTTP you only have three significant operations (one of which, DELETE, isn’t being used) – retrieve (GET) and update (POST): in particular there’s no distinction between creating and updating. That might sound like a trivial point, but there’s significance here that is being overlooked.

CRUD is defined in the context of databases where what you’re dealing with is sets of information – you need to make a distinction between inserting into the set and updating an existing member of the set.

Meanwhile HTTP was designed for access to resources, the “primary key” being determined by it’s URL (vs. having to worry about the insert id). If you think “documents”, it’s clear there’s no need to make a distinction between creating and updating – creating a document results in the first version. Updating means overwriting an existing document with a new version. But in both cases the client is POSTing the same thing and does not need to be aware of whether the document already existed or not.

Meanwhile a common first demo app for server side frameworks is a CRUD example. The implication here is frameworks place a strong emphasis on the database, while HTTP is largely ignored (it’s rare to even see HTTP status codes as a fundamental part of a framework).

Avoiding a long filesystem vs. database discussion (like the need for virtual file systems with extensible properties) suffice to say – consider how Dokuwiki stores wiki pages 1-to-1 as files compared to MediaWiki. What makes more sense to you? Perhaps our websites have been driven too far by the database?

The point here is, given the mismatch between HTTP and CRUD, we’ve put CRUD first which in turns makes actions first class in our frameworks. We aim to support N different types of action (verbs) when really we should have been dealing with only three – GET, POST and DELETE (the latter being perhaps re-routed to a specific “resource class” method according to some framework / form conventions).

Back to Beyond

Returning to this point, the conclusion today seems to be, rather than abandon MVC, abandon Java (or Perl / PHP / Python) in favour of a platform that reduces lines of code – “MVC with the least amount of pain please”. MVC is synonymous with our requirements for better web application development – “You want better practices? Use MVC”.

But what about extracting what we actually want as an independent list – forget about MVC for a moment? Off the top of my head (and not at all comprehensive);

  • Nannying: tell me how to get organised – clear signposts for where to put my code.
  • Just add water: give me my prototype now!
  • Don’t make me think: I can do this stuff even on my dumbest days.
  • DRY: making the same change 50 times is not cool.
  • Anti-pasta: help me avoid spaghetti
  • Security: no nasty surprises please. Help me get this right first time.
  • Testing: help me protect myself against myself.
  • [insert more here] x N

So far I haven’t come up with anything that can only be solved by MVC (and some have nothing to do with MVC at all).

Perhaps there’s a better pattern suited to the web? Perhaps the “controller” in MVC implies emphasizing “actions first”. If we demote actions in favour of resources supporting just GET, POST and DELETE, perhaps the controller is handled for us automatically by the framework?

Anyway, for lack of a better place to end this, a quote from The Register on Wheat;

And after the very first Sunday presentation, one audience member claimed he found the new web programming language Wheat “so beautiful, it’s made me cry!”

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.tonymarston.net Tony Marston

    When people say that MVC may not be suitable for the web what they actually mean is that they have not seen an implementation that they consider suitable for the web. The point is that there is no single definitive implementation of MVC (or any other design pattern, for that matter).

    Your idea of MVC for PHP is right on the mark:

    * Model—those functions that wrap calls to your db
    * View—the templates / scripts that output HTML
    * Controller—the stuff that examines variables like $_GET and $_POST and works out what to do next

    I have followed this outline in my own implementation:
    * Model – a series of classes, one per database table
    * View – a series of reusable XSL stylesheets
    * Controller – a series of reusable include files.

    Note that my Views and Controllers are all reusable, and are based on a series of transaction patterns (component templates). This means that the programmer can spend the vast majority of his time on writing the business logic in each model unit (table class) and not have to waste time in reinventing the wheel everywhere else.

    So it’s not the pattern itself but the implementation that counts.

  • Ezku

    In a way, the whole issue is based on false premises. Every web application has to have all elements of MVC: decision making based on input (Controller), storing/retrieving data (Model), responding with output (View). It’s just a matter of how these three are organized. Mingle them all together and you’ll get spaghetti, but the elements are still there. From a proper design perspective it only makes sense to separate these three – the degree, though, is debatable.

  • myrdhrin

    It always come back to the same basic principles… no matter what you call it.

    1. Decouple you implementation as much as possible
    2. Use common sense

    No matter how you do it, by function layers, by objects, by interfaces, if your implementation is decoupled you’ll have a cleaner code.

  • http://www.tonymarston.net Tony Marston

    From a proper design perspective it only makes sense to separate these three—the degree, though, is debatable.

    The degree is not debatable. You either have separation into three distinct units or you do not. Each unit must then be readily identifiable as being one of the Model, View or Controller. If you don’t have 3 separate units then you don’t have MVC. If you do have 3 units, but the responsibilities of the Model, View and Controller are shared between them, then again you don’t have MVC.

  • Dr Livingston

    In that sense, the layer below should not know about the layer above it, but remember both a model and a view are to some extent, interwined; they are in effect, not separate.

    this whole debate about mvc i feel a lot of developers see this as being the holly grail of web development; they spend a lot of time and expel a lot of effort to comform to it.

    the feeling i get is that they – the developers – don’t feel comfortable until they reach out and touch mvc; in effect they may well feel that they are inferior developers if they don’t seek mvc route.

    is it crap? the more i think about it and the more threads i read on the forums about it, from inexperienced developers, the more i think it may well be crap ;)

  • http://www.tonymarston.net Tony Marston

    In that sense, the layer below should not know about the layer above it, but remember both a model and a view are to some extent, interwined; they are in effect, not separate.

    I disagree. In my implementation they are totally separate by virtue of the fact that the View (html output) is created from an XSL stylesheet which contains absolutely no domain (business) logic. The Model component is a PHP class/object which contains all the business logic and absolutely no html. That sounds ‘separate’ to me.

  • spags

    MVC is very doable in web applications. I wrote a couple articles on it for CodeSnipers, I called it “Stupidly Easy MVC in PHP”

    http://codesnipers.com/?q=node/156&&title=Stupidly-Easy-MVC-in-PHP-or-

    Now, I can’t hardly stand to program NOT with MVC :)

  • pdxi

    What? This is blasphemy! :)

    Over the past few years, I’ve developed my own application structure methodology which resembles MVC. Why? Because: A) It works, B) it’s simple and easy to replicate, C) It makes reusing code very easy, D) It’s very easy to expand an application laterally with this structure.

    Now what’s wrong with that?

  • 123

    Given that we have enough miles on the ASP.NET clock now, the impression I get is experienced web developers are wary of ASP.NET because it’s “too smart”—the learning curve to mastery is significant and there’s perhaps too much clever stuff being done transparently in those web controls

    If by “experienced” you mean “i wrote cgi once”, then probably yes. But I never saw decent devs with OOP background who got lost in ASP.NET because it is too smart or learning curve is significant.

    People afraid of things they dont understand. Just because you can’t comprehend how ASP.NET lyfecycle works or logic flows throught the event handlers code, it doesn’t mean that the system itself is complicated and obscure.

  • nicoss

    With HTTP you only have three significant operations (one of which, DELETE, isn’t being used)—retrieve (GET) and update (POST): in particular there’s no distinction between creating and updating.

    False, 4 operations (and more) in HTTP : CRUD = POST, GET, PUT, DELETE. With Ajax you can easily implement the 4 verbs on your web app, delete and put include.

  • arborint

    Pretty good write-up Harry, but I think you are not only flogging a dead horse — you seem to be quoting a lot of opinions as facts and basing your whole on it. A the heart of your article, I think, is when you say this:

    “What I’m really trying to say here is I think the desire for MVC on the server side is a result of obsessions with forms, limitations of Javascript, the desire to compete with desktop apps and that form method=”DELETE” never happened (so it was necessary to bundle this as another action via POST the action).”

    I really think you are lost in Http-land in this article. You seem much to preoccupied with the detail of the web (and belief that it is soooo different) and have lost sight of the universal need for clean dependencies.

    If MVC has a failing is that it is not called MP+ where MP (Model Presentation) is considered the the baseline for good applications and MP+ is simply a good enhancement. The MP separation is probably 90% of MVC. It is also probably one of the hardest things for programmers to implement well, yet the one with the greatest benefit.

    Rather than muddying the waters, please use your column to rant about the importance of Model Presentation separation, or how View Controller separation is venue for programmer creativity. But please keep the discussion about web application design moving forward. Rails has moved the bar and hopefully something like the Zend Framework will bring ActiveRecord to the PHP masses. Yes, that’s right, the PHP masses using an actual pattern and achieving some MP separation. Now that’s a good thing.

  • Trent Reimer

    Ha! I like the idea of considering what a REST-ful framework would look like. I’m of the opinion that MVC is mostly popular because it works. Who’s to say a REST-ful framework wouldn’t be better?

    But I’m not convinced AJAX has quite yet obviated the need for the “document” approach to the web, especially as hand held devices begin consuming more of the internet. Perhaps in the future even text mode browsers will be Javascript and XMLHTTPRequest compliant?

    If that does happen will we see web programmers begin specializing in either client or server?

  • http://www.addictedtonew.com/ jnunemaker

    Harry,
    I don’t believe you have muddled anything. Just because MVC works and seems to be the best option at this time doesn’t mean that something better isn’t on the way. I believe this is the point of your article. Don’t just run with MVC because it seems to work the best. Stretch yourself. Try to come up with something better. Thanks for the interesting and thought provoking read.

  • Pingback: Follow or Forge // Archives // Addicted To New

  • Pingback: Fiftyfoureleven.com Web Development Resources

  • Buddha443556

    The mismatch is between HTTP and CRUD and the problem isn’t with MVC pattern either. The problem is between the programmers and the servers. As programmers, we want maintainable code. Unfortunely the servers find that code slow and resource intensive. PHP is a scripting language and the more we optimize the code to our needs as programmers the less our servers like it. We need to step back and rethink the problem. We can have the best of both – fast and maintainable code. It’s not a hard problem to solve … believe me. ;-)

  • http://www.phppatterns.com HarryF

    Picking up some points;

    First of all I’m most definately not arguing against making seperations like MVC. There seem to have been quite a few reactions to this that assume that’s what I’m getting at (my fault for being too wooly).

    That said, what may be the case is there are different seperations that a framework could expose to you – going through the docs / tutorials in activegrid, there’s a far greater emphasis on “workflow”, for example – controllers seem to be something that happens implicitly – handled automatically by the framework – you don’t need to think / code in terms of controllers.

    Also, view-centric code can also written in a manner which has clean seperations – spagetti is not necessarily always the result.

    “Given that we have enough miles on the ASP.NET clock now, the impression I get is experienced web developers are wary of ASP.NET because it’s “too smart”—the learning curve to mastery is significant and there’s perhaps too much clever stuff being done transparently in those web controls”

    If by “experienced” you mean “i wrote cgi once”, then probably yes. But I never saw decent devs with OOP background who got lost in ASP.NET because it is too smart or learning curve is significant.

    Was referring more to a “control” thing – control over exactly what get’s send to the browser. What ASP.NET does with viewstate, for example, is regarded by some as an ugly hack – it makes server side event driven programming possible but the cost is too high for some. Also controls which generate HTML for you don’t tend to blend well with CSS purists.

    Over the past few years, I’ve developed my own application structure methodology which resembles MVC. Why? Because: A) It works, B) it’s simple and easy to replicate, C) It makes reusing code very easy, D) It’s very easy to expand an application laterally with this structure.

    Now what’s wrong with that?

    Nothing at all. If you wrote it for yourself, it surely makes good sense to you and meets the requirements of the types of application you are building. But would it make sense to everyone else / meet their requirements?

    “With HTTP you only have three significant operations (one of which, DELETE, isn’t being used)—retrieve (GET) and update (POST): in particular there’s no distinction between creating and updating.”

    False, 4 operations (and more) in HTTP : CRUD = POST, GET, PUT, DELETE. With Ajax you can easily implement the 4 verbs on your web app, delete and put include.

    You’re right – was neatly brushing over a bunch of stuff with the use of the word “significant”.

    What I was trying to get at is HTTP’s method “API” resembles a typical filesystem API more closely than it does SQL’s “API”. Another method we’ve left out: “HEAD” seems to me to parallel a stat call.

    More to the point, GET, POST and DELETE are all you really need to manipulate resources without having to “tunnel” methods through other methods. DELETE needs to be explicit as there is a difference between POSTing an empty document (a “NULL”) and actually deleting a document.

    When using POST to create something new, if it’s something like a document in a tree no problem. If it’s the next element in a sequence, e.g. a reply to a forum discussion, you might have a special URL (e.g. http://example.com/forum/someDiscussion/tail) which new comments are POSTed to then you redirect them via a 302 when the comment is stored on the server.

    Good point regarding AJAX – I haven’t placed with other methods than GET and POST via XMLHttpRequest but have seen Javascript webdav client (webdav is another story…).

    Pretty good write-up Harry, but I think you are not only flogging a dead horse—you seem to be quoting a lot of opinions as facts and basing your whole on it.

    If it sounds like opinions as facts, I apologize. The article I started with makes a good point to begin the discussion but my MVC angst comes from personal experience and this blog is really a result of examining yet another framework. What’s depressing is I’ve been down this road before long ago and abandoned it – Catalyst has elements in common with ISMO, albeit ISMO is not as well defined – the quick hit of URLs to class methods feels good to start with but it goes downhill from there.

    Regarding dead horses – I think it’s fairly safe to safe that 10 years from now, very few new web apps will be written where MVC style form processing happens server-side – why does xforms have a model tag for example (note I’m not saying xforms is the future, just that people are looking in this direction)?

    I really think you are lost in Http-land in this article.

    Perhaps but have a question there: how do you tell the browser to cache the following URL?

    http://example.com/item1/update

    I.e. how do you cache a verb?

    Does your framework help you identify the things that are cacheable from those which aren’t?

    Part of this is about ending HTTP abuse.

    Rather than muddying the waters

    If there waters are muddy, pretty sure it was the person in the bath before me.

    Ha! I like the idea of considering what a REST-ful framework would look like. I’m of the opinion that MVC is mostly popular because it works. Who’s to say a REST-ful framework wouldn’t be better?

    It’s intesting that people have only seem to have considered REST in relation to web services. Somehow think if you seperate form processing from resources, then implement “local HTTP” so you can call those resources without actually opening a network connection (i.e. they are objects), so your form processor can call them, it’s starting to look like a REST-ful framework.

    I don’t believe you have muddled anything. Just because MVC works and seems to be the best option at this time doesn’t mean that something better isn’t on the way. I believe this is the point of your article. Don’t just run with MVC because it seems to work the best. Stretch yourself. Try to come up with something better.

    Thanks and that’s the basic jist of it. “Better” might be something that fits well with HTTP (allowing you to take advantage of HTTP’s caching capabilities for easily, for example – saving bandwidth) and it might also mean something that “makes sense” – you’re not wasting your brain time on inventing new names for “actions” (e.g. “getLatest”, “addToCart”, “listByGroupDesc” etc.) but rather thinking about the resources you are delivering to a client.

  • willthiswork

    Reply recieved! Thanks a lot.

  • http://www.phppatterns.com HarryF

    Here’s something I’d completely missed: http://trimpath.com/project/wiki/TrimJunction

    TrimPath Junction is a clone or port of the terrific Ruby on Rails web MVC framework into JavaScript.

    Is it safe to say this is the first MVC implementation in Javascript?

  • arborint

    Perhaps but have a question there: how do you tell the browser to cache the following URL?

    http://example.com/item1/update

    I.e. how do you cache a verb?

    Does your framework help you identify the things that are cacheable from those which aren’t?

    I think part of my point was that mixing a discussion of MVC and something like Caching ends up with neither being very meaningful.

    Is the question “how do you tell the browser to cache the following URL?” or WHETHER you tell the browser to cache the following URL?. If you ultimately cannot guarantee how the client will cache something — how do you handle that? There are several strategies, but none have anything to do with MVC.

    So I’m wondering how you got from HTTP related transport and caching issues to MVC?

  • Charles Polisher

    As far as I know it first showed in Sun’s Model 2 architecture somewhere around 1999(?) then crystallized into a specific (and popular) implementation: struts, around Y2K.

    Krasner and Pope published their seminal paper on MVC in 1988, “A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System”.

    From there, put bluntly, it seems to have become a self perpetuating mantra or tech lemming syndrome.

    An early criticism of MVC was published by Marc Evers in 1999, “A Case Study on Adaptability Problems of the Separation of User Interface and Application Semantics.”

  • http://www.phppatterns.com HarryF

    So I’m wondering how you got from HTTP related transport and caching issues to MVC?

    Because I think HTTP caching illustrates the problem well – that MVC (or at least common web based implementations of it) pit you at odds with HTTP. It’s a specific benefit you gain or lose depending on how painful it is to write the code to take advantage of it.

    If your framework encourages you to think in terms of verbs, you will need to identify those verbs which correspond to GET vs. those which correspond to POST yourself, then implement the caching of the GET-type verbs.

    What’s more, if you leak those verbs directly into the network interface (the URL), you enter the realm of HTTP abuse. What if someone bookmarks a URL containing a verb like “add” accidentally, and every time they return to your site, they “add” something new, unknowningly? To avoid that leakage, have seen some frameworks employ an additional layer of abstraction, between actions and URLs, but that makes working with the framework painful in my experience.

    By contrast, if your framework gives nouns (resources) a higher priority than verbs, caching might be something the framework can handle for you automatically – any given noun object might have a property “lastModified” which you simply need to populate with a value. When the noun objects GET method is called, the framework looks up the lastModified value for conditional GETs.

    “As far as I know it first showed in Sun’s Model 2 architecture somewhere around 1999(?) then crystallized into a specific (and popular) implementation: struts, around Y2K.”

    Krasner and Pope published their seminal paper on MVC in 1988, “A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System”.

    Sorry – I inserted a paragraph where perhaps I shouldn’t have – was specifically talking about the point where MVC showed up in web applications (not desktop / fat client UIs);

    So why did MVC become a common pattern (or at least a common term) for web applications, bearing in mind it originally evolved for to help building desktop GUIs?

    As far as I know it first showed in Sun’s Model 2 architecture somewhere around 1999(?)

    An early criticism of MVC was published by Marc Evers in 1999, “A Case Study on Adaptability Problems of the Separation of User Interface and Application Semantics.”

    Thanks.

    Otherwise, here’s something interesting just ran into – Rewriting Reddit leading to web.py (not yet released);

    The third principle is that web.py should, by default, do the right thing by the Web. This means distinguishing between GET and POST properly. It means simple, canonical URLs which synonyms redirect to. It means readable HTML with the proper HTTP headers.

    And this code snippet;

    import web

    urls = (
    ‘/(.*)’, ‘hello’
    )

    class hello:
    def GET(self, name):
    if not name: name = ‘world’
    web.header(‘Content-Type’, ‘text/plain’)
    web.output(‘Hello, ‘+name+’!')

    if __name__ == “__main__”: web.run(urls)

  • Pingback: The World According To Sebbi » Model-View-Controller

  • Benjymouse

    The Model-View-Controller pattern is not an archetype pattern. Rather, it’s a composite pattern, consisting of Observer, Composite and Strategy patterns. Implementations may use even more patterns like Factory, Decorator etc. (ref. the GoF book, pages 4-6).

    Most obvious is the way that the controller observes the view (listening for events) and the way that the view observes the model (in the active variant of MVC).

    Events are merely an implementation detail of certain languages. The Event paradign simplifies implementing e.g. the Observer pattern.

    To differentiate between event-driven and MVC is therefore misleading. Events are inherently part of MVC, even if the events are not formalized but rather discovered through inspection of posted data and/or dispatched using a switch statement.

    In ASP.NET the event-driven codebehind takes the role of the controller: It observes changes in the view (subscribing to events) and manipulates the model. The latter of course depends on whether you implement a 3 tier approach or just let’s the controller go to the database.

    The ASP.NET databinding implements another important part of the MVC pattern: The View “observes” the model. Again, some developers may opt to bind directly to a database, but databinding can be done against any tabular (or hierachical from 2.0) datasource, including e.g. arrays or lists of business objects. Again, if you design a 3 tier architecture you will inadverdently code a MVC pattern when using ASP.NET.

  • http://www.thinkedit.com onclephilippe

    Very interesting article

    I’d like to know if you are still behind this : http://www.phppatterns.com/docs/design/the_front_controller_and_php

    This is very interesting stuff, and imho the hardest to master when bulding an application. In MVC, it’s the “C” that’s hard to do well. I read your two php antology books, and they don’t speak alot about the controller; because there is no single good answer?

    I guess we’ll see a lot of interesting stuff happening on this part of web developement.

    The uggly truth may be that however you design your application, one day you have to do something bad because you didn’t think about it before.

    And wathever you do, you cannot overcome the fact that http is stateless.

  • Pingback: sjon.blog » MVC - nothing new there is it?

  • paul_lomax

    I couldn’t agree more… I’ve almost got to the point of rejecting any CVs which have ‘MVC’ listed in their experience now.

    I don’t suppose you’re looking for work at the moment…? :-)

  • Pingback: SitePoint Blogs » a simple wiki with web.py

  • Pingback: Nederhoed » Blog Archive » Something is wrong with the MVCs I see

  • Pingback: Vysnu » MVC and web apps: oil and water

  • Pingback: SitePoint Blogs » PHP Security: Dumb Users or Dumb APIs?

  • Pingback: Jumping on the MVC Bandwagon at d3 eMinistry blog

  • Pingback: Steve’s Log » Blog Archive » MVC and web apps: oil and water

  • M.Uma Sankar

    Differences between 3tier architecture and MVC

  • cesium62

    MVC is used because you want to be able to use the same functionality through multiple interfaces. We used MVC in 1997 without knowing what it was called because we wanted to interface our database not only to users via HTML, but to other web sites via Soap, to Sabre via EDIFACT, and to Wizcom via some other random protocol. When you have N implementations of your controller and view, and one implementation of the the model, you use MVC. And lo and behold, this is pretty much what a 3 tier architecture provides.

  • martynas

    This article was one of the inspirations :) And so we developed our own RESTful PHP framework, based on Resources that have URIs and implement HTTP methods.
    http://www.xml.lt/Resources/Framework

  • Justin

    I’d like to know what you think about a JavaScript MVC framework like Junction (http://jupiterit.com/junction.html).

    It allows a more natural development because you have access to data (exposed through services) and the DOM at the same time.

  • James Watt

    I completely agree with this article. Nice read. I have actually thought this for some time now, but never wanted to take the time to argue the point.

  • faffy fuck

    “This might just mean finding smarter ways to write view centric code, emphasizing DRY while avoiding spaghetti – consider the “article.php” in this URL.”

    Are you by any chance talking about a recipe for soup?