phplondon08 – the 'crazy guy' mail

As you’ll know from my previous post, I was ‘heckled’ during the Q&A of the framework talk I did. This wasn’t aimed at me, but rather at all 3 of us on the panel, and more importantly, at ‘MVC’ frameworks as we commonly see them today. Marcus Boniton also mentions this incident on his blog.

Personally, I don’t think he’s a crazy guy, I just like the title and find it quite amusing 😉

I pointed the ‘crazy guy’ to my previous blog entry, where he replied to an author of one of the comments, and CCed me in. I thought it was a very interesting mail, so it’s included below. I put this here with full permissions from Mike.


My name is Mike. I am the “crazy guy” from the London framework debate, as you called me on Ian’s blog. I am 28 and I live in the Middle East. I am the propaganda officer (a fancy title for a guy who looks for interesting people and drags them in) of the Agavi project, but despite coming off as a loudmouth, I actually managed to restrain myself during the so-called debate because I realized that if I push it any further I would be met with anger and not a listening ear . I suppose having opinions gets you this sort of treatment sometimes. Either way, I think it is unfortunate that in a room of well over 300 people, only five actually listened to what I said and approached my team after the debate with genuine concern and curiosity (Ian, in all fairness, was the first one to come). In fact, it’s quite sad that the applause I received was more due to my sarcasm than the actual point I was trying to make.

It appears that you are one of the people who missed the point, so I think I should clarify myself so that you have a decent opportunity to assess whether you have a right to call me crazy or not. If you feel like it, feel free to forward this rant to UK PHP community.

All major Rails clone PHP frameworks that exist on the market today are a complete and utter failure. All of them call themselves MVC frameworks and none of them implement actual MVC. In fact, some of the worst ones merely resemble MVC, and have no right whatsoever to be called frameworks. Whatever benefits of sexy ORMs and flexible build systems and scaffolding and other secondary tools these frameworks have are nullified by the fact that using them results in architectural chaos which is no better than your usual spaghetti code. This is because the people who wrote Rails didn’t bother to understand MVC, and the PHP amateurs who were excited about the idea of getting done more in less time blindly tried to clone Rails into PHP and in so doing not only replicated the stupidity of Rails into PHP but also multiplied it by their own incompetence and PHP’s shortcomings as a language and a platform. Here’s a great unrelated example of a person espousing nonsense without having a first clue what they’re talking about and other equally ignorant people supporting him:

In a true MVC implementation, the application itself resides in the model. The model is a wrapper in which the developer expresses the application as an API in terms of the business problems that the application solves. No part of the controller-view chain has anything whatsoever to do with the application logic. Controllers are not allowed to make assumptions about the user interface presentation, and views are not allowed to perform changes in the application’s state. In proper implementations, database access is wrapped inside the MVC models, and templating is located underneath the views. Controllers can’t set page titles, and templates can’t query the database. DAL specific output formats can not cross the boundary of a model. Rails-style helpers have no place in the MVC architecture. All these are factual rules of MVC, and the frameworks violate them left and right, including Symfony, Cake, Trax, Seagull, and many others whose names I can not recall. MVC dictates in very clear terms what goes where which wouldn’t be a challenge had anyone actually spend an hour thinking about it. Of course, everyone is too busy deceiving their customers and writing code that can not ever be fixed.

I have been actually approached by a couple of people trying to argue that MVC can be interpreted in many ways. That is ridiculous. If one of the basic constraints of MVC is violated, the whole codebase becomes infected with code that will need to be taken out before forward compatibility that MVC promises can be invoked. If you ever need to replace the database backend, or completely swap out a session storage, you will be surprised to discover that the MVC magic has evaporized and you now have to spend next months rewriting the whole thing and then hunting down bugs caused by the rewrite, which will inevitably lead the project into its bitter end.

In all three presentations that were shown to us in London, horrible mistakes were made in the example code, not by way by programmers’ shortsightedness or sloppiness, but because the frameworks themselves were designed in such a way that making these mistakes was a fundamental requirement of the frameworks to the point the programmers don’t even realize that what they’re doing is completely wrong and harmful. I hoped that the newer releases of the frameworks that I reviewed in the past would realize what they’re doing and correct their mistakes but it is too late now. It appears to me that many people which consider themselves veteran PHP developers who think they’re sufficiently endowed to educate the public (and I do not mean to imply here that these are the same people as London conference speakers) can not recognize neither these mistakes themselves nor the devastating implications propagation of these mistakes has on both their own career and the PHP developer community as a whole, more often than not because their idea of web application architecture is limited to the mentality of PHP 3 age and the notion that PHP is something that turns a database into a web page.

In other words, 95% of the people who say they do MVC have not actually read the MVC papers, have not thought the whole thing through, and have not done anything to verify that the ridiculous nonsense they’re parroting has correlation with reality. These frameworks proliferate and multiply at great rate. It is the textbook example of irresponsibility and incompetence. What’s even more disturbing is that the PHP developer public has lost its ability to think critically, which makes me think that I don’t really want to be a part of this public. The stupid and dangerous actions of this public also cast their shame on me and other developers who do not make the same mistakes as the rest. Right now, the Java developers have a field day laughing at us.

When I was speaking, sarcastically, about all three frameworks being broken, at the point I said the word “criminal” there was laughter and applause because people love the shock value. If anyone actually bothered to listen instead of clapping their hands, they would have let me continue to make my point, which was that what is being in marketing materials of all Rails clones is false advertising, which is in fact a crime in many places, and that people who use these frameworks are about to face some very unpleasant questions from their past employers.

MVC makes certain promises which the PHP developers love to pass on to their customers. Nevertheless, when doing their jobs, these very developers do the exact opposite of what MVC requires them to be doing in order to be able to deliver on their promises. The net result of that is that in a year or two when new protocols evolve and new technologies arrive, people who relied on the cheap programmer labour that is enabled by shiny self-proclaimed MVC frameworks would suddenly discover that their applications can not scale without a full rewrite, and all of the funds invested in development and maintenance of their business are now down the drain. When that happens, I’ll be quietly watching in the corner and watching the lawsuits and the fireworks. The reputation of PHP as a platform will be damaged beyond repair, but hey, who cares about cutting the branch you’re sitting on as long as it makes you fat dollars, right?

I’m glad that some people have actually listened and will hopefully reconsider their reliance on other people’s ignorance before it lands their asses in hot water.

I have the option of going around slamming other frameworks directly and naming names, but why should I waste my time? None of them can be fixed without forcing everyone who uses them to abandon everything they’ve written so far. I’ve got what I need and I am damn sure I am not getting angry phone calls long after I’m done with my projects. Do you still think I’m crazy?

If nothing else, the email is at least an interesting read! It’s also my longest blog post ever, though very little work of my own! 😀

59 thoughts on “phplondon08 – the 'crazy guy' mail”

  1. this guy is nuts, and at the very least he should be branded a member of the pattern gestapo. While he makes some valid points about how people tend to put more code in controllers than models these days, that’s not the fault of some of the frameworks. he simple doesn’t seem to get the point in patterns, of which MVC is one: The autohors didn’t writ it to be an all encompassing hard fast rule for the next million years. Infact, back in 1988 when the authors write the MVC pattern, there wasn’t even an interweb!

    20 years laters, we have a whole lot more knowlege, a whole set of new technologies, and more importantly, a whole lot more experience. This
    experience has time and time again taught us that the academics are not always right, and infact the particioners in the industry often come out on-top over what academia had to say in the first place. After all, i don’t see such smalltalk in the real world, why? Because it’s an inpractical language for real world use.

    One of the most important skills in being a praticioner is to identify when parrts are useful, when they need to be slightly modified from their original purpose (perhaps due to implementation detail, or perhaps because they didn’t initially envisage the use they you wanted to use them for), either way, that doesn’t make patterns not useful for what they were designed for – a method for documenting and communicating underlying software design to others, not as a hard fast set of methods that is the only thing you’re allowed to use in your code.

    In regards to various frameworks calling themself MVC’s, perhaps this idiot should take a think about what M, and V, and C all stand for. Then perhaps he could try and match them up with the frmaeworks concept of view, controller, and model. I think funnily enough for an MVC frmaework, symfonly seems to be fairly well endowed in the Model, View, and Controller. All be it perhaps it’s not used in eacrtly the way the original 1988 paper thought it for.

    Additionally, there is absolutly nothign to say that MVC is the only way of doign things. Infact, i’m becoming more and more enamoured with the page/component model introduced by microsoft, which far better suited for dynamic complex page layouts (as commonly seen in “admin interfaces”) and AJAX than MVC will ever be.

    Use the tools you’ve got, and create new ones to do what you want to do if they don’t exist (or, modify existing ones). Don’t cubby-hole yourself just because 2 guys wrote a paper 20 years ago that while being well designed, wasn’t the solution to teh interweb.

  2. Having been using Symfony for the past 2 years, I’ve come to settle on the muddled approach it takes in comparison with a true MVC structure, mainly because it provides a middle ground where beginners and proficient developers can find support with the framework. True, business logic here is contained within actions and views, but this violation is certainly justified by the high learning curve. This system has proven itself in enterprise, high load and demand environments (speaking from personal experience) and has allowed other developers not yet familiar with the OOP approach to expand their knowledge of a better way of doing things.

    Having said that, I still agree with the majority of well-argumented points Mike (may I call you Mike? ;-)) made in his email – Symfony is not a true MVC framework. There, I said it. But just as AJAX is used wrongly everywhere (I’ve even seen straight JS effects being referred to as an AJAX library), the term MVC has become a marketing buzzword, which inherently brings a broadening of the meaning of the word. This is just a fact of semantics – English is a living language, and there are tons of examples where certain words gradually lose their original meaning. I think arguing about whether MVC is the correct label for Symfony is like arguing whether Moo.FX should call itself an AJAX library or not (and I’m referring only to the FX part, not the whole of MooTools, that actually contain AJAX-related functions). Things change, and in order to proliferate a better approach to doing things, you have to use buzzwords in the way they are commonly used in order to approach a broader community, not just pattern zealots.

  3. I think Mike maybe has an incorrect view of at least symfony (I’m not sure about the other frameworks). On the symfony website, the framework is being advertised with the words: “object model and MVC separation”. This does not mean that the framework is a full implementation of the MVC pattern, but that it has seperation of the three layers MVC recognizes. I dont’ want to make a word-game out of it, but this is an important distinction.

    Having said that (and admitting I am not fully up to speed with the exact MVC specifications), symfony does allow one to put all business logic in the model layer, it does allow you to set the page title in the vie. However, the framework is flexible, and so it it also possible to set the page title in the controller, and also allows you to put business logic in the controller. That it’s possible, does not mean it should be done. The reason it is done is

    a) people’s lack of understanding of the full MVC specification
    b) a concious decision to use another approach because it fits better for the project
    c) a combination of the two

    Declaring all people working with these frameworks to be criminals and incompetent developers is a bit short-sighted. While I do recognize some valid points, the way they are made is maybe not correct.

  4. I agree with Mike that many frameworks are based on bastardised implementations of the MVC pattern.

    I’m not sure that so many people will hit the problems / pain of having to adapt and modify a code base to be flexible and meet the changing needs – which would have conceptually been easier if they had utilised the MVC pattern correctly.

    However, I’m pleased that the adoption of these frameworks has rocketed, rather than invent their own spaghetti which has plagued PHP communities for years. I just hope (and will probably be disappointed) that PHPers challenge these implementations or even understand the implications / limitations of frameworks.

    I think the merge in distinctions between the web and desktop applications that we are beginning to see (think Gears / Air / Silverlight) will really challenge these frameworks as the coupling that enables you to develop quickly for the web, will become obstacles for being able to deploy the same application for different environments without code duplication.

  5. Hi Theo,

    First of all, I think calling other people idiots should be avoided. You call me an idiot, I pick on your spelling, and downwards goes the spiral. So, let’s not call each other names shall we?

    Now I would like to relate to what you said.

    It really doesn’t matter whether MVC is applied to stateful bidirectional UIs such as desktop windowing systems or stateless client-server systems such as browsers over HTTP. It also does not matter whether MVC papers were written 20 years ago, as the principles behind them remain the same.

    MVC insists on isolation, which guarantees forward compatibility and other benefits. Isolation relies on commitment from the developer, which means that the developer must have a clear idea what can and can not be done within MVC. The moment you violate the isolation, forward compatibility is lost. Let me give you an example.

    The company I work for developed a product with an Ajax frontend. The product is a multiplayer game, and as such it has more or less intricate states. Having developed the Ajax frontend, we realized that the UI is too heavy for Ajax, unavoidably so in fact, and players with older PCs or broken browsers (and there’s quite some) can not compete fairly with players who do not have such a problem. We have decided to write a flash client for the game.

    The amount of effort we needed to invest to make it happen is near zero. In fact, the only thing I needed to adjust in the code base was adding a new template which loads the Flash client. Everything else was new code to ask views for information that they already construct and encode it into XML that Flash can read. Had I do the previous work amateurishly, I would have had to go around all the actions and views and edit them to throw out HTML and replace it with XML rendering. Better yet, the game now can simultaneously work with Ajax *and* Flash client – and Agavi is so flexible it allows me to hook up a QA bot which actually plays games with live players, using the same API the JSON client does.

    When you work on long term projects, you can not afford to get away with “most useful skills” as you describe them. It is your obligation, as a developer, to foresee the changes in your customer’s vision and ensure that there is space to fit into them. When you do MVC properly, this is not a concern at all because MVC architecture itself ensures that you can. When you do this in an ad-hoc way the way the other frameworks do, you suffer the consequences.

    Well, except that you don’t, because when your current project is over you say “job well done” and disappear leaving your unwitting customer with broken software.

    I proudly consider myself a professional, and I believe the software I write is solid and will keep being scalable in five-ten years from now on. It is a fact of life that software grows in unexpected directions. Developers who choose to ignore this fact in favor of a quick buck are committing fraud. Developers who do not understand the problems I am describing here at all are ignorant.

    Here’s a great example of ignorance:

    In this example from official symfony documentation, the action – that is, the MVC controller – is commanding an HTTP forward to another action. This is a gross violation of MVC, because redirection is an UI concern and not application concern, and when you need to hook up, let’s say, a XMLRPC response to your actions, you will have to go all over your code and add if() statements so that the redirect doesn’t happen for XMLRPC requests. You will be writing duplicate code and you will be breaking the old one.

    I don’t want to even talk about the fact that a framework is supposed to be completely agnostic to application specifics.

    No, MVC is not the only way to go. It is, however, a *great* way to go, and for most web application tasks, it’s the best balanced way to go.

    Back in nineties I walked through a russian flea market which was flooded with cheap chinese knockoffs of brand name CD players and tapes. They were branded “Funaiwa”, “Sonny”, “Hytachi” and such. They were designed to look like they were original high quality products but they weren’t. This is the same case as with pseudo-MVC frameworks. The reasoning and excuses of the vendors who create these are exactly the same: they’re able to make more money in less time selling poorly disguised fakes, preying on ignorance of their customers. This is in essence the position that you are defending, and you should be ashamed of it.

    The bottom line is, most current frameworks that brand themselves as MVC can not in principle deliver the benefits of MVC, and the applications written with them are not different from

  6. But, Stefan, when the majority of developers is ignorant and short-sighted, what is the proper semantic construct to let them know about that? 🙂

    The framework shouldn’t be allowing you to do X and Y; it should be actively preventing you from X and Y if X and Y are the pinnacle of wrong. That is why I am so outraged about the slides on the debate – even the basic example code, which is supposed to represent all code ever written for the framework – had architectural mistakes presence of which suggests that any projects that do things the same way the examples do are in trouble.

    In the coarse language, calling Cake et al applications MVC is the same as calling rape a date.

  7. Quote: “However, the framework is flexible, and so it it also possible to set the page title in the controller, and also allows you to put business logic in the controller. That it’s possible, does not mean it should be done. The reason it is done is a) people’s lack of understanding of the full MVC specification b) a conscious decision to use another approach because it fits better for the project”

    Allowing the framework to be so flexible which allows you to set the title in the action/controller in my opinion is an hugely unpractical, there is absolutely no defense to prevent or warn of such a stupid acts, this will create a generation of newbies who think its perfectly correct to write from anywhere to everywhere, so using the argument that its to solve a development solution is a lazy approach. 🙁

    How are you meant to promote good practice (and I come from personal experience here) if no rules are enforced to prevent silly practice such as this, if I started programming with symfony and was allowed to use this flexibility, it would of sent me off in the wrong direction, this may be a problem with my abilities yes, but now I’m hugely thankful for using a system with strict rules so I learnt by the fact it won’t execute unless its correctly done. Now how can you argue with that?

    On regards to your point “a”, if you have a lack of understanding of MVC, why are you not attempting to learn it, if you want to create a application with MVC, the least amount of respect you can give is to at least grasp the main principles, but with non-compliant frameworks, you are allowed to flaunt this and hack together an application which becomes telephone switchboard connectors all over the shop, good MVC practice (*STOPS*) this and so doesn’t allow you to create spaghetti (as the terminology does) unless you go out your way too.

  8. Mike: Again, symfony does not pretend to be a full implementation of MVC, they only claim to have a seperation of the layers as defined by the MVC pattern.

    Flexibility is not wrong by default in my book. It allows you to adapt to a situation. I do not like to be restricted to MVC in the most strict sense. Maybe you like it, I don’t.

    In the end, symfony is a web application framework, and as such, I am very happy to use it. I also think that it is very accessible and easy to learn, and so will introduce usually “script kiddie” PHP developers to more proper coding techniques. They will either understand why proper coding is right and go on to learn more about it, or don’t see the need for it and don’t. And either way is fine. It’s just a carreer path one choses for him/herself.

    As for your example of an AJAX interface that gets changed to Flash: Aside from some of the excellent points you make (such as redirects in the action), such a change would still be relatively easy in symfony.

    I am going to propose you to talk at the Dutch PHP Conference, because I’d like to see you make your points in a talk. I think you have some very valid points, but I also think you’re too strict in thinking your approach is the only correct approach.

  9. Stefan,

    There can not be a “full” or “partial” implementation of MVC just as there can’t be “full” or “partial” pregnancy. You can’t have “MVC based” or “MVC inspired” frameworks that are not proper MVC because there is zero MVC benefit in something that is not MVC.

    I will gladly accept your welcome to the Dutch conference and I hope I will be able to attend it and give a talk.

  10. @Theo

    Smalltalk isn’t impractical for realworld use.

    I’d say that it didn’t become mainstream simply because the marketting of Sun Java was better than that of any Smalltalk vendor.

    At a time when Java/C++ was being given away for free, Smalltalk vendors were trying to charge licencing fees. There’s still a vendor today (name escapes me) that’s charging $8000 per developer for the privilage of using their SmallTalk VM.

    SmallTalk is certainly *not* an academic langauge. It was created in the industry by Xerox PARC.


    Everything else you said. I agree with.

    The MVC model as stated in the past isn’t the end-all-be-all. If you’d rather not call the Rails/Symfony/Django systems MVC, I’d be happy to agree. Call them something else, just don’t call them useless.

    Personal story.

    I worked with a newbie developer in Symfony. In his first project, he jammed everything into the view. The controller was empty. The model was used merely to grab DB rows. Everything, all the logic was in the view.

    I worked with him to seperate out the layers and get closer to the MVC ideal.

    A lot of people want to say: “The framework should force you to do MVC purely. The framework should enforce the rules”. I don’t think the framework is any place to be enforcing rules. Individual developers should be mentored and taught ‘the right way’. This kind of thing shouldn’t be baked into the framework.

  11. I share a lot of opinions with this guy. I haven’t fully delved into the nitty gritty of the official MVC framework definitions, but I thought I understood enough to realize that the current “MVC” frameworks don’t fit with what I understand MVC to truly be.

    I think the only flaw Mike makes is going off on the lawsuit tangent and everything going down in a big inferno. Companies have been dealing with and settling for inferior products for quite some time. The need to rewrite a project a few years down the road when the pseudo-MVC framework fails to scale or adapt will just be considered the normal write-run-rewrite-repeat process that has been going on for years.

    Now, if non-geeks wise up and realize a lot of geeks are slacking off and could be writing much better code, we’ll all be in trouble.

  12. Mike,

    What, then, do you recommend? I dabbled in Cake and really didn’t like how the three layers seemed to “bleed” into one another. I’d love to use a framework that actually worked like MVC should.

    Also, I noticed that you mentioned scalability towards the end of your email (rant? I don’t mean that negatively though). The days when PHP could be accused of not scaling are long since past, and I feel like your arguments as a whole are a bit influenced by an anti-PHP prejudice. Now I’m no PHP evangelist, but do you think that a competent, compliant MVC framework would be possible in PHP?


  13. If that guy spent as much time writing actual documentation and tutorials for his PHP framework as he did writing novel-size responses and heckling people at events, maybe more than 3 people would actually look at and use this “Agavi” framework that he claims is so great.

  14. Mike, I agree with you. Yes, there no semi-pregnance woman and there no semi-MVC framework. It is binary value: yes or no, true or false.

    The only thing I want to ask is: what you propose to do? You have used ‘most’ word. Does it mean that at least some frameworks are really MVC?

  15. Mike,

    I think you are being a jerk. You can call other people and their ideas ignorant, criminal, ridiculous, poorly thought out, short-sighted etc… but if someone calls you an idiot it is inappropriate?

    In my experience a strict interpretation of MVC leads to more implementation work and greater difficulty developing an application. The reality is that most projects use a single UI and do not implement a secondary Flash client. In my experience javascript/ajax is lighter than Flash. I wonder if your javascript UI suffers from trying to follow an ivory tower mode of MVC? Perhaps your team would have been better served by writing a better javascript client then doing a bunch of work to develop a Flash client.

  16. *In a true MVC implementation, the application itself resides in the model. The model is a wrapper in which the developer expresses the application as an API in terms of the business problems that the application solves. No part of the controller-view chain has anything whatsoever to do with the application logic. Controllers are not allowed to make assumptions about the user interface presentation, and views are not allowed to perform changes in the application’s state.*

    I agree.

    The *Controller* takes care of all the HTTP stuff (requests, responses, routing, sessions) and glues everything together.

    The *View* is normally an HTML/XML/JSON representation of a part of the application in a certain state.

    The *Model* is your application logic. It should be decoupled so that you could take your models and make command-line scripts that interact with it (or reuse in other ways).

    I know that you can achieve this structure with ZF and CI (and no doubt others): so I’m not really sure what the beef is?

    PHP is a “get the job done” language… I’ll gladly sacrifice academic perfection for real-world gains.

  17. Mike says:

    In a true MVC implementation, the application itself resides in the model. The model is a wrapper in which the developer expresses the application as an API in terms of the business problems that the application solves. No part of the controller-view chain has anything whatsoever to do with the application logic.


    From the Agavi documentation:

    The Model accesses your data. It might talk to a database, or to a web service, or use smoke signals to acquire the information it returns to you; the essential point is that the way the data is retrieved is absolutely irrelevant to the code that uses the model. So in the beginning, your application would use models that return “fake” dummy test data for rapid prototyping, and later, you will write the actual code that talks to a database.

    The View presents your data. For Web sites, that typically means it renders an HTML document from one or more templates. But it could also build an RSS feed from the data it was given, or create a JSON data structure for the Ajax functionality of your application – it’s all up to you!

    The Controller contains the business logic: the code that talks to the model, transforms the data, performs necessary tasks and then prepares data for the View. In Agavi, we call this the Action. After it has finished its task, it tells the system which View to use to generate the output.


    And finally, from Wikipedia:


    The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items).

    Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.


    Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.


    Processes and responds to events, typically user actions, and may invoke changes on the model.


    I’m in agreement with keeping application login within the modal. The point of separating out the logic is so you can have different interfaces to it. You should be able to control the application, for example, from the command line.

    I think the Agavi docs need an update… no?

  18. And that, Mike, is shortsighted.

    Of course you can have MVC-based or MVC-inspired frameworks. Maybe not in your narrow vision on MVC, and maybe it won’t use the full power of the MVC pattern, but even if it uses half the power of the MVC pattern, then it beats using no framework bigtime.

    I truely don’t understand your near extremism in this. Sure, you use a better approach (at least in your eyes), that’s great, but that doesn’t make me a criminal at all.

  19. He’s absolutely right and touches on my largest issue with the PHP community in general.

    When we set about rebuilding after a vendor had totally screwed it up, we surveyed every “framework” under the sun and found none of them were pure MVC, and, at worse, complete architectural failures.

    Two common problems were encountered. One, the architectural chops of your standard, and even above standard, PHP developer are just not up to the task. No amount of reading design pattern books is going to help the maintainers of a lot of these frameworks in any way. There is a special kind of experience that, in general, these people lack and it shows when you scrutinize their work. The second issue we ran into is that people design these frameworks as though they were doing it for other languages and not PHP. You simply can’t do that because PHP is what it is. It is not Java, it is not Python, it is not Ruby.

    Your controller should not be specifying which view to render. It should not be setting page titles. It should not be “rendering partials”. Once you’ve leaked in user interface related stuff in your controller, you wipe out half of the benefit of using an MVC pattern for application development. Your controller is no longer “portable”, it is no longer “testable” and now it is completely tied to your presentation layer and can only become divorced through hacks and kludges.

    Hate all you want, but the crazy guy is dead on the money and you should pay attention to what he has to say if you want your precious frameworks to be taken seriously by people coming from other languages who’ve used frameworks that adhere to MVC principles.

    Cake, in particular, is god awful wannabe garbage that’s a shining example of the sort of amateur level of knowledge that seems so pervasive in the PHP world.

  20. The fact is that RoR (or any other framework I’ve looked at) can be used to write spaghetti code that’s just as bad (or worse) than anything written without the aid of a framework.

    This is not surprising, as the frameworks weren’t designed to enforce MVC (difficult or impossible to do), therefore you can stick any kind of logic anywhere you like. That’s not the real problem, although it would be nice to have frameworks that could enforce MVC constraints.

    The problem is that people aren’t doing real MVC. One thing that immediately stands out as “broken” in the Rails code I’ve seen is the use of the “find” method in controller code. This seems to be everywhere.

    From the “cookbook” tutorials:

    @recipes = Recipe.find(:all, :conditions => [“category_id = ?”, params[:category_id]])

    What’s wrong with this? The controller is telling the model what data to get for a particular view! This is a trivial example, but the model should control what data is exposed to the controller/view, not the other way around. (E.g., Recipe.find_by_category(category_id)).

    What happens if, in your non-trivial application, you need to restrict access to data? You *could* just modify the code in your controller, right? Wrong. Someone who’s not aware that model logic is splattered throughout your controller code will come along, make a change to your model, and break all kinds of stuff in the controller code. Yes, it might seem like an unnecessary level of indirection, but isn’t controller (or view) code easier to read, write, and debug when it isn’t full of model logic?

    The long and short of it is that people need to take the time to understand MVC, and the various framework communities need to promote better coding practices. (E.g., don’t fill your tutorials with non-MVC code!) Otherwise, it’ll be the amateur PHP developer problem *all* *over* *again*.

    PS: I’m also aware that you could redefine the “find” method in your model so that it enforces any restrictions you need, *but* that means that it will behave in ways unexpected by anyone who’s not aware that you redefined it. Imagine redefining something like fopen() in C…

  21. Guy honestly, ignore this person Mike, he’s attacking other open source projects, and that’s pathetic, and makes him look like a fool, the PHP community has nothing to do with him or his crazy ideas.

    He’s no expert when it comes to frameworks, he just writes crap and attacks those projects that made it.

    Ignore him.

  22. So you’re saying that pointing out flaws in open source projects is “pathetic”?

    Like Ian (and about half of the commenters here), you’re not addressing any of his criticisms. You’re just engaging in name-calling.

  23. I assume by ‘Ian’, you’re referring to me – at which point am I name-calling? I’ve actually stayed clear of this discussion on here – but for what it’s worth, Mike and I have spoken about this, both at the conference, and online, and there is NO hostility between us, and I have agreed with some of his points. I don’t appreciate your trying to bring down my name on my own blog. Please think before posting.

  24. Well, can’t help but wade in when someone launches on MVC. I just can’t help myself. While I acknowledge that Mike Seth knows a bit about MVC, he makes a lot of statements that really overstep the definition of the pattern and are more implementation specifics or just plain opinion. It is very clear that he believes that Agavi’s implementation is superior. He also seems to have a dislike for Rails.

    The first thing I would like to note that MVC has more zealots than any other pattern. This zeal is really about frameworks as you can probably tell. If only the Decorator or RowDataGateway patterns had such competitive supporters! I think it is also important for readers to to acknowledge that the implication that there is such a thing as “a true MVC implementation” is an opinion. It is a very odd statement about a pattern in general.

    I generally agree with Mike’s opinions about implementing MVC. However he uses a good amount of vague language while demanding absolute obedience. Take for example his statement “the application itself resides in the model. The model is a wrapper in which the developer expresses the application as an API in terms of the business problems that the application solves.” The Model is obviously part of an application, but he uses the words “resides” and “expresses” which have no technical meaning and allow him to fudge a little there.

    Mike also uses a rhetorical technique when he insists that MVC cannot be “interpreted in many ways”. Maybe true, but that does mean that it can only be interpreted or applied in one way. A good example of this is the slight differences you will find in how the dependencies are defined in different definitions and implementations of MVC. And the idea that deviating from Mike’s one true way will “infect” a code base ignores all the other methods, such as modularity, that are commonly used by programmers.

    Curiouser is this statement that MVC somehow promises “forward compatibility” (whatever he might mean by that) and that it can be “invoked”? Strange indeed. Sounds more like marketing than programming.

    Likewise his statement of “MVC insists on isolation” is vague. The term “isolation” does not a specific software meaning that I know of (like modularity, separation, dependency or layering) — so it is difficult to know what is actually meant. MVC specifies a separation between the Model layer and Presentation layer, and a separation within the Presentation layer between the Controller and View. It also defines dependencies. Much of the rest of what Mike insists on, is in my opinion, not in the pattern.

    Finally, I think Mike does not acknowledge the many contributions over the years to our understanding of MVC. Sun with Model 2 or frameworks like Struts and more recently Rails have all had a effect on how MVC is implemented. Remember that MVC is not a religious truth, it is a tool that we use to solve problems. As the problems being solved have changes (like the advent of web applications) so have best practices in solving those problems.

  25. Ian, I apologize for my somewhat-vague wording.

    What I meant was that you (and many commenters) have not addressed the substance of Mike’s criticisms. This ranges from a lack of comments on your part (what *do* you think, anyway?) to refutations (“complete and utter baloney”) that lack anything resembling an explanation of why Mike is wrong.

    The remark about name-calling was directly squarely at koder.

  26. The way that guy talks about php, and php developers. It is so degrading. Why is it so important to try and bring down these open source projects and php? Are you trying to prove that everyone should use what you use? I actually do think you are crazy, and a jerk.

  27. Jees, I’ve skim read this whole page and don’t think I’ve got any benefit. The most I got is that I’ve learnt of a new framework called agavi, but went on to find out that there’s barely any documentation, even the API docs don’t look that good. This sounds like a lot of ranting and raving, PHP frameworks are there to help, the more available, the more choice we have to develop the way we wish.

  28. Well theres probably the most famous book on patterns:

    Design Patterns: Elements of Reusable Object-Oriented Software

    Kevlin Henney (who gave a great talk at last years PHPLondon conference and pointed out that patterns are still being created / implemented / documented) has co-authored a number of books:

    Books on Pattern-Oriented Software Architecture

    On Patterns and Pattern Languages

    So theres some great material out there!

  29. Actually, if you all just forget the animosity for a while and focus on the matter discussed, you might reach some consensus.

    First, it’s been already pointed a few (a lot?) of times that what web frameworks are calling MVC is not really MVC. The confusion started with Sun explaining their notion of models “1” and “2” of Servlet/JSP application arquitechture. People then wanted a better name than “Model 2” and just called it MVC.

    The problem is not that a pattern can or can’t be open to variations, the problem is when you change a fundamental property of the pattern. In the original MCV pattern, elements were related/connected in a certain way:

    – The model, as the name suggests, models your data (it doesn’t actually matter if it *is* your data or if it just accesses it).

    – The controller acts on the model.

    – The view represents the current state of the model.

    · So… communication could be represented this way:

    Controller —> Model —> View
    (sometimes you’d also say the View sends events to the Controller, but that’s actually not relevant to the pattern)

    This means the Controller acts on the Model. Then the Model is seen through the View.

    · In current so-called-MVC frameworks, the diagram is somewhat different:

    View <--> Controller <--> Model
    (sometimes you also get communication between Model and View, where the View could query the Model)

    This means The Controller acts on the Model and receives the data back, and then passes it to whichever View is appropiate.

    This change makes the Controller the central point of the pattern and arguably changes the pattern in a fundamental way, making it, imho, a different pattern.

    Remember, patterns are not things we arrange or fit into our developments. What they are is a compund of:
    – a certain problem
    – certain constraints
    – a solution known to be good for it.

    What people fail to see is that the constraints these web frameworks are working with are different than the ones in the original MVC pattern. And so the solution is somewhat different too… But still they’re calling it MVC.

    So, what happens is that actually “Model 2”, Rails, etc, are implementing a different pattern but are still calling it MVC. Is “implementing a different pattern” bad? No, not at all. Is “calling it MVC” bad? Well, imho it is at least confusing.

    Now… just what pattern is it? Is it PAC (Presentation-Abstraction-Control)? Is it MVP (Model-View-Presenter)? PageController, maybe? A different one?

  30. Doh, should’ve previewed…

    The “so-called-MVC” diagram shoudl be something like this:

    View {–} Controller {–} Model

    (change the curly brackets to angles in your mind making those two-way arrows, please 🙂 )

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

  32. Thank you for saying this Gonzalo!

    I’d like to point out a few things, mostly to emphasise a few points Gonzalo made.

    The MVC *framework* was implemented in 1976-8 somewhere and described publicly in 1978-9. The MVC *pattern* was described at least a decade later.

    Frameworks are *not* patterns. In an object oriented framework you are meant to provide concrete implementations of predefined classes. The framework establishes the architectural connections, not your extension code.

    Patterns are descriptions of solutions to specific problems.

    I refer you to Ralph Johnson if you want to know more. He started work with frameworks in the 1980’s (and most of our definitions are due to him) and later patterns (he’s one of the co-authors of the Patterns book). Actually check this guy out if you don’t know him… in addition to frameworks and patterns interesting connections to things like sunit (leading to junit), the first refactoring tool, Ward Cunningham, Kent Beck, and a lot more.

    Programmers are notorious for loosing important distinctions and being forced to reinvent. MVC framework is not the same as MVC pattern is not the same as Model 2 is not the same as Rails… Unfortunately we have a tendency to call them all ‘MVC’ — and now we don’t know what we are taking about and get into fights. This happens all the time and if I spent a moment I could come up with dozens of them.

    MVC is a specific framework, and has been represented as a pattern. Even in the smalltalk community there were disputes over the utility of MVC and certainly over specific details — even Parc Place tweaked it adding things called values, if I recall, that could be shared between M, V, and C (but this didn’t actually change the MVC part). But they (other than Parc Place) didn’t call the diverging implementations ‘MVC’ and so they could speak clearly without appearing to contradict each other. There’s nothing wrong with diverging from MVC but before you do you’d do well to understand what you are diverging from.

    As to another comment someone made, there’s a trade off between doing something really quickly and doing something that withstands change. The difference is time and quality. You’ve heard about this trade off before: do it quickly or do it right. Both have their places, but before you trash the quality of a true MVC solution you’d better understand what that quality is. I don’t see a lot of evidence that this is understood. Don’t dismiss the replacement of an Ajax front end with a Flash font end. I had to do it the other way around (flash to ajax) and I am very happy that we were ruthless in our enforcement of MVC (of course implementing it in a proper framework makes it easier to enforce ruthlessly in that it doesn’t look ruthless 🙂

  33. Hi there,

    I find this discussion very interesting as a few weeks ago I was about to start using Agavi on a new project, and decided for Symfony “last minute” instead, and I was actually pretty happy till after reading this debate here I now feel like a ignorant hacker who’s going to be sued for defrauding my clients. 😉

    First off, I think Mike’s right about a lot of things, albeit I don’t believe unpure MVC practices will bring about the apocalypse right away.

    What I think is not being touched on here is the possibility that the rapid adaptation of frameworks happens because they address the development needs of small to mid-level sites. I think there is a large layer of projects that never mushroom into anything bigger, and that will never have JS vs. Flash (or both) interface issues, so it’s easy to see why a lot of developers get away with unpure separation, and that may not be bad, because it’s necessity driven. It only *becomes* bad *if* requirements change drastically, and that’s where the professional judgment factor that one of the previous posters mentioned comes in.

    That being said, I would *like* to think that I’m building future-proof applications and Mike’s points got me thinking. One of the distinctions I saw between Agavi and Symfony is that it considers “context” within the routing, such as web-request vs. xml / json request, and that would partially decide what action is used and what view is rendered. Is there such a thing in Symfony?
    Secondly, I guess I’m getting a little confused. What’s bad about having the controller (the action in Sf) retrive view-specific data? After all, the controller knows best what view is about to be rendered, and what data is needed for it. How would the model know?

    PS: My choice of framework is pretty much summed up in timtims comment, that there was just no good documentation on Agavi at the time (and I believe still isn’t). Especially compared to the wealth of community support Symfony enjoys going with Agavi would have been a business risk.

    Looking forward for more comments 🙂
    Have a great day everybody.


  34. There’s a really good article from Terrance Parr (of ANTLR fame) on MVC that you really should also read: He goes out of his way to clarify why the separation of concerns is important.

    I’m not sure why everyone is so quick to attack (or even defend) the languages and frameworks mentioned. Anyone with discipline and experience can properly implement MVC using any framework I’ve seen. The real problem isn’t the tools we’re using, it’s the lack of wisdom, training, and maturity in the developers. We need to read more, learn more, and question everything.

  35. Hi Josh,

    Thanks for your follow up there, I appreciate it. I posted my opinions in a seperate thread this morning. I won’t pretend to be an expert in software engineering, I have a lot to learn and I’m happy to spend time doing so. I’m not so much interested in arguing this point, as I can see huge advantages in symfony, and I’ll continue using it for the time being. Maybe it blurs a few lines here and there, but for me, it’s about getting things done – symfony’s admin generator, and the plugins providing drop-in functionality is a huge benefit – and if it costs me a bit in terms of compromising strict seperation in my apps… well, that’s ok with me. It’s also ok for my current clients of small/medium size sites, who almost always just want things done – just a website that is almost certainly going to stay just a website – not a API provider, not a flash interface, not a GUI app.

    Consider me on the fence – I’ll hop onto the ‘greener’ side when I have more time to invest, but I’m mostly leaning onto the not so green side, because I know what that grass tastes like, and for now, it tastes good enough 🙂

  36. just to add my 2 cents to discusion. i’m a symfony user, and there are many changes in symfony 1.1 that more adheres to MVC paradigm, and symfony alway encourage the fat models and thin controlers.

    And i think that is more of a programers job to enforce MVC on his way of development.

    and if i remember correctly symfony was using agavi as a MVC implementation.

  37. symfony is a fork of Mojavi MVC framework, not Agavi, but I think I read somewhere that Agavi is also based on Mojavi (?) so in that case both frameworks share a common parent.

  38. Paul, don’t get all this wrong please. Now you want Mike to talk about MVC in the london meetings, have you gone mad?? Come on man, give us a break!

    Have you used Agavi before? I’m guessing you never had. This guys Mike is no expert, make no mistake about it, if you think he is, it’s only because he uses the correct terminology when attacking other frameworks.

    Experts, when they go to conferences don’t talk, they listen. Then, if they think they can improve something, they do it by writing code, not narcissistic emails.

  39. Now I am going to laugh at you. Are you saying that only non-experts speak on the conferences? Or, are you saying that you’re only willing to listen to non-experts? If experts don’t speak at conferences, which is apparently how you see it, then who does?

    That’s ridiculous and you, without having the slightest idea who I am and what I do, instruct people on how to relate to me and my professional experience? LOL.


  40. Again, all wrong. I’m talking about experts attending, not speaking (read carefully, it’s not hard).

    Although you are dying to speak in front of a public you’ll never be listened, because no one listens to fools. There’s no place in the PHP community for ignorants that attacks the work of other programmer. Not here, not in a conference, not you. And stop saying: “You are all wrong, I’m right. My MVC is better than yours!”. Save it crazy dude, we heard all that crap before.

  41. So let me get this straight. You dismiss the possibility that your code is shit, reject any criticism preemptively, and then call other people ignorant?

    I don’t want the rest of the drama, thank you.

  42. I think Mike is right. The way he presented his thoughts might not have been the best one, since no one enjoys reading criticism to the frameworks they develop or use. But the principles he pleads for are very healthy. I don’t know if he is right about those frameworks or not; I have no experience with them. But the fact of the matter is, there are a lot of frameworks and tools out there which trade strict rules and architectural robustness for ease of use and steep learning curves.

    I acknowledge the benefits of both these approaches:
    – coding by strict rules in order to get a reliable architecture which can easily adapt to changes, etc;
    – making compromises in order to develope an application very fast;
    Each one has its strengths and weaknesses and in the end it all comes down to what kind of application you want (and afford) to have. There is, though, in my opinion, a very serious issue with the second approach. Of course, by following it, a developer may not be forced to break healthy architectural rules. Like it has already been said in this discussion, everyone is free to chose for themselves. Unfortunately, though, even if not forced, the developer is encouraged to take the rule-breaking approach, because most (not all, but most) people, when facing a decision will almost always follow the easy way. In this case, this leads to mediocre code writing principles.

    Once again, I am not talking about one or another framework in particular, but about the principle of building clean architectures and not breaking pattern rules. I hope I haven’t offended anyone with my opinions and if I have, please accept my apologies. I assure you, it hasn’t been intentional.


  43. Koder, you say that no one listens to fools, but I must respectfully disagree with this opinion. At least one person has payed attention to what you had to say… me.

    And if you are a PHP developer, as I guess is the case, you would better hope you have been wrong on your next statement, also.

  44. It’s so funny to see how people behave when faced with information which doesn’t sit with their understanding of things.

    There is no question Mike is right on just about everything he says – the problem is the forceful uncompromising manner in which he expresses his opinions. It just gets people’s backs up.

    The truth is that many of the current frameworks do not enforce the separation between layers that a good Computer Science textbook would advocate to get the right amount of encapsulation, decoupling, etc.

    But, alas, they are the best we have and are certainly better than going at it alone from scratch.

    Perhaps the code in these frameworks is not something one would submit for a phD thesis, but they do accomplish the goals they have set out to do, which is to get development done faster and smarter.

    They are practical professional frameworks which work. They are not academic frameworks which are more “correct”.

    Perhaps Agavi will become the be all and end all, eventually. Who knows? There are so many moving parts: the size of the community, the available addons, etc, etc.

    Agavi may end up being the purest MVC implementation. If what Mike is describing is true, and if they stay true to their word, it sounds like they are going in a great direction.

    But in the meantime, which is probably the next year or two, I am quite satisfied with cakePHP. It may not be perfect theoretical MVC, but it’s a heck of a development framework for getting things done reasonably and quickly.

    And you know what, for 95% of the web apps most of us develop and will develop, it is more than enough.

  45. MVC most likely began as an idea formulated into a concept, then a architectural programming approach which evolved into Smalltalk (a framework). In terms of an architectural pattern, MVC was designed to solve a problem and in essense is one possible solution for solving that particular problem. From a pattern point of view, Smalltalk implements a specific collection of design patterns and applies those patterns in a specific way.

    Other framework flavors of a similar nature attempt to solve the same problem in different ways. Each of these frameworks applies their own collection of design patterns, and each of those subordinate patterns was designed to solve a low-level problem, many of which could be applied or implemented in different ways (e.g., Mediator, Observer, etc.).

    MVC was described in the POSA book as an architectural pattern among the other architectural patterns described in the same book along with a semi-strict explanation of how MVC architectures should be designed to operate as an MVC design pattern (i.e., explicit collections of design patterns are mentioned along with their applied usage).

    Since MVC is one way of solving the same problem which is apparently obvious based on the proliferation of frameworks intended to solve the same problem, MVC would probably be better described as one possible implementation for solving the separation of concerns, categorized under a higher level architectural pattern classification that encompasses all other solutions for resolving the same architectural problem.

    Corraling all other architectural approaches similar to the original MVC concept which are intended to solve the same architectural problem into the pattern classification of MVC, seems to be more of a mistake made by the academic community.

    In the past, we’ve seen similar arguments. For example, there was a discussion a few years back after the announcement of HMVC and how similar it was to PAC. Anyone who has used both PAC and HMVC knows that both architectures were designed to approach the same problem and both used different collections of design patterns to achieve the same goal with different handling of the separation of concerns.

    Personally, I feel that architectural patterns need to be classified more strictly based on the subordinate design patterns they apply and how those patterns are applied (which can differ considerably in some cases). Coralling all MVC-like frameworks and their underlying architectural approaches under the MVC pattern name seems like the cause of much of this discussion and a considerable source of confusion.

  46. No framework, no pattern is a solution for stupid. Stupid developers will make stupid msitakes

  47. Referring (allbeit some months later :-)) to the comments of all application logic going into the model I think there has to be a balance.

    A good example would be, if you are using an ORM engine could you switch it to another ORM engine and by changing only the model part of your app get the whole thing working again? Probably not in 90% of cases because you have calls to the ORM layer in your controllers.

    You could say then all calls to ORM must go into the model in the form of static functions, for example User::getAllActiveUsers() etc. But then what if you want to page those users or get them in a different order than the default? Soon enough you’d either end up with a hell of alot of static functions or yet another layer in your app that abstracted the ORM technology you are using. Now if the ORM technology in your app was a concern and likely to have to change then this probably would be the direction to take but if not then why spend all the time building it in?

    As I think someone else here has said, personally i’m glad that I’m not forced to do things in a particular way and I think that a framework giving you some freedom like that is a good thing, it places the responsibility with the developer to get the application design right. The only reference to the above mentioned examples I have is symfony and as far as I can see it implements ‘model 2’ (the term MVC to me refers more to the classic use of it in stateful apps) perfectly and while giving you the ability to break certain ‘best practice’ principles – like outputting to the view directly from the controller using the reponse object – it also allows you to adhere to those best practices just fine.

  48. I thought I’d add that I’m wrestling with a badly written bespoke MVC-ish application in PHP. And learning about how people think about MVC by reading StackOverflow.

    I’ve come to the conclusion that attempts to do MVC in PHP should instead be called DMVC, the D meaning Data. This is because so many frameworks make the Model the Data and then where do they put the application logic? They usually mix it between the Model and Controller and that ain’t pretty and loses all the advantages of data abstraction. At least if we added a letter to the description people would realize how many frameworks simply get MVC so badly wrong.

  49. I think, the framework is flexible, and so it it also possible to set the page title in the controller, and also allows you to put business logic in the controller. That it’s possible, does not mean it should be done.thank you very much for informing to me .good work 🙂

  50. The problem there is not that the frameworks make you write bad code, the problem is that those frameworks are the bad code, they have 3 or 4 tasks per super class and then the user extends from those classes in an “static spree” attempt, the same as including the damn “util.php” that I hate so much.

    I guess the problem is not the fruits that are those frameworks, but their developper’s roots in bad OOP.

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.