My non-conclusion about MVC

A you might has been in my previous post there’s quite a discussion about how a lot of PHP frameworks break MVC.

I stayed clear of commenting, as I didn’t want to get drawn in, however one comment did ask what I thought, so here it is!

So, let’s start at the very beginning, for it’s a very good place to start. What is a design pattern?

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

The documentation for a design pattern describes the context in which the pattern is used, the forces within the context that the pattern seeks to resolve, and the suggested solution

Source, wikipedia

One point here that I feel is important, is that it it’s a ‘suggested solution’ – not a concrete definition. At some point, what you implement might differ so much from a patterns suggested solution, that it should no longer be called by the name of that pattern.

At some point in all this, someone has suggested that the implementation in symfony (and similar frameworks) ruin scalability. I don’t believe this to be the case – certainly Yahoo would argue with this point at the very least!

The general feedback I got on the day of the conference, was that Mike might well have had a good point, it’s just he came across badly whilst making it. It appeared he was being a little hostile, but I put this down at least partly to a foreign accent and didn’t see any true hostility at all. In fact, I thought that he added color to the presentation 🙂

I’m still learning about programming and software architecture, and I think anyone in the programming industry that claims they aren’t still learning it’s lying, an idiot, or amazingly smart – but probably not the latter!

I’m going to spend some time looking at Agavi soon, I’m certianly interested in improving my toolkit. I’ll probably post my findings here, who knows – maybe Mike will have been responsible for a conversoin me over to Agavi

I said this at the conference, and I’ll say it again here – I think it’s important to look at a number of frameworks, so you know what’s out there. This means that when faced with problem X, you’ll know that tool Y is the correct solution. Symfony has a fantastic admin generator system, that allows for really fast RAD. It might blurr the line of responsibilities between what it considers to be the ‘M’, ‘V’, and ‘C’ – but sometimes it’s about getting the job done, not about creating a work of art.

I’ll also point out, that symfony allows you to replace many parts of it, especially in the upcoming 1.1 version. You can swap out the Request, Response, View components, and a whole lot more.

My conclusion is a bit of a non-conclusion. Essentially, it comes down to this. If you don’t want to call symfony, cake, rails etc MVC – don’t. I dont’ care – and I might even agree with you. Mike has some valid points, I’m taking them on board and hopefully I’ll improve because of it.

3 thoughts on “My non-conclusion about MVC”

  1. Wise words – keep on learning – its a good moto!

    Unfortunately, the web industry seemed to ignore many of the lessons already learnt in the software application development world and as such has gone through such a similar history.

    For example, Software development learnt long ago that Waterfall methodology when applied often failed. They created / adopted / moved to more agile methodologies and they showed great success and adoption is slow in the web industry, but is happening.

    Design and implementation lessons have also been ignored, Smalltalk is a great example of an Object Oriented language, but was largely ignored by the community as a whole. The web industry instead went through a transformation from functional to object oriented principles. Paradoxically, design patterns were also sidelined and then people started adopting them for their web applications.

    The end result is a process that has been so accessible to all (because of its simplicity) has also meant that important learnings have been ignored – don’t be one of the ignorant masses! Learn, understand, adopt, change (yes be bold!) and feedback to the community, not everyone will understand or even want to hear what you have to say, but in the end it can only be beneficial.

  2. “If you don’t want to call symfony, cake, rails etc MVC – don’t. I dont’ care”

    Ignoring the point that all those go beyond the implementation of that single pattern they revolve around, I’d like to point out that we, people, tend to give things names for various reasons.

    One of those is to be able to identify them for what they are. Another is to be able to understand each other. And I’d guess this is the main reason for Mike’s commentary.

    But we also use names as a psichological weapon, as a means to gain confidence over things. We give names to acquire familiarity with them, to confine what could be a vast array of concepts and details in one of two words. Imho, this is the main reason a lot of things get called MVC. At my workplace we even have a framework that’s called just ‘mvc’ and people refer to it as MVC v3 (which is kinda sad for a name, I must say).

    So… the conclusion I reached a while ago is:
    When people say MVC in a web context they just mean a way to separate those three concerns. And I know that, and they may or may not know that, but I don’t actually care much as far as we both understand eachother and what their/our code actually does and how it works.

  3. “someone has suggested that the implementation in symfony (and similar frameworks) ruin scalability”

    I’ve seen no case studies suggesting any scalability problems encountered with any of the current php/mvc frameworks.

    Rails on the other hand has been done to death and the conclusion I came up with was down to engineering.

    I’m sure there are far bigger problems ahead (bridging CDN’s with SOA’s?) than the situation dev’s face today, meh, can’t we all get along 🙂

    As for the Smalltalk adoption rates, I think you can blame the training industry for that, always pushing for more coboal dev’s, and for what?

    as for the term MVC, i’ll go with whatever floats your boat.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.