Why Do PHP Developers Think MVC Is An Application Architecture?

I’ve pointed out before that Model-View-Controller is a user interface pattern, not an application architecture. But why would PHP developers get the idea that MVC is an application architecture in the first place? (This may apply to all server-side developers, not just PHP folks.)

I used to think that MVC was an application architecture. Even after reading Fowler’s POEAA and seeing that MVC was for the user interface, I figured that meant I was doing “user interface applications.” But that was not quite right; it would have been more accurate to say that I had been mixing the concerns of user interface with the underlying core application.

Based on that experience, I think the reason MVC is mistaken for an application architecture is because PHP developers generally start with page scripts. In our first page scripts, we combine all the concerns in a single ball of mud: SQL queries are intermingled with HTML, and the business logic is scattered throughout. As far as we are concerned, the page script itself is “the application.” Later, as more functionality is required, we add another page script, and another, and another. We continue to see that collection of page scripts as “the application.”

Then, as we progress in our profession, and begin to learn how to better organize our work, we start separating the different concerns of “the application.” When we begin separating concerns, we separate them out of the page script, which we see as “the application.” Extracting the view concerns from the page script means extracting them from “the application.” Separating the model from the page script into its own layer means separating it from “the application.” Pulling the controller logic out of the page script means pulling it out of “the application.” So of course Model-View-Controller is seen as an application architecture – we separated the concerns of our application according to that pattern, right?

Except, in retrospect, it’s not. One of the big leaps we have to make is to realize that MVC is for the user interface portion of our systems, just like Fowler notes. We on the server side think the user interface is HTML, CSS, and Javascript, but it’s not. Instead, the user interface is the HTTP Request and Response. In other words, the template is not the View.

Once we make that conceptual leap, we begin to realize that the Model layer is the entry point to “the application”. That is where “the application” should live, or at least where it should look like it lives. The Controller should have little to do but take input from the Request and pass it to the Model; likewise, the View should do nothing but put together the Response using the output from the Model.

With that idea of server-side MVC, we then begin to see that a lot of what’s in server-side MVC frameworks is “too much.” Framework functionality that is not related to merely taking input from a Request and presenting output through a Response becomes entirely secondary to, perhaps even actively harmful to, building well-structured applications – applications that are independent of any particular user interface.


The server-side MVC pattern, as descended through Sun’s Model 2 architecture, is so distinctive from the client-side MVC pattern as to be a completely different thing. I realized this as I was writing my book on modernizing legacy applications, and further research led me to write up Action-Domain-Responder as a web-specific alternative to MVC. Action-Domain-Responder places a much stronger emphasis on the HTTP Request and Response as the user interface elements. If you are interested in building better applications, you may wish to read the ADR essay, and try it out in your next project.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

15 thoughts on “Why Do PHP Developers Think MVC Is An Application Architecture?

  1. Actually ADR is just an MVA. And most of backend php frameworks (Laravel, Symfony) uses Model-View-Adapter pattern to separate data presentation (HTTP in most of the cases) from application.

    Hail separation of concerns.

    • Actually ADR is just an MVA.

      MVA is one of the patterns I failed to note in the ADR essay, in the section comparing ADR to pre-existing patterns. I’ve been meaning to add it to the essay (along with a lot of other things).

      I don’t think ADR is the quite the same thing as MVA. Quoting from https://www.palantir.com/2009/04/model-view-adapter/ :

      The Adapter holds a pointer both to the Model and to the View and directly calls methods on both. At the same time, it attaches itself as a listener both to the Model and to the View in order to receive events. It receives property change events from the Model and action events (checkbox ticked, text entered, etc.) from the View, and then routes appropriate changes to the other side. The Adapter is entirely responsible for keeping the Model and the View in sync; the Model and View are both relatively dumb structures, knowing nothing about the other.

      If that description is accurate, it sounds like an in-memory GUI system, not a client-server or request-response environment. Also note that the Action in ADR (which would be the Adapter in MVA) is not responsible for “keeping the Model and View in sync” via event listeners, since there are no event listeners in ADR.

  2. I think one of the other problems that confuses people is that the “M” in MVC is not the same as the “M” in ORM, even though they are both for “Model”. I think this is what makes a lot of people think they need to put all their code in the controller, because they think the model part of MVC is just for their ORM classes.

  3. I personally don’t care whether people call MVC an architectural pattern or an interface pattern or a foobar pattern – it is still a software pattern.

    In my own framework I started with the 3-Tier Architecture with its separate Presentation, Business and Data Access layers but because I split my Presentation layer components into two which followed the description of the View and Controller I discovered later that I had accidentally implemented the MVC pattern, with my Business layer providing all the Model classes.

    In this implementation all business knowledge – data validation, business rules, task-specific behaviour – exists in and ONLY in the Business/Model layer. I have actually turned the Views, Controllers and DAOs into nothing but services which are built into the framework as reusable components. This means that application developers need only concern themselves with the components in the Application/Business layer.

    • I personally don’t care whether people call MVC an architectural pattern or an interface pattern or a foobar pattern – it is still a software pattern.

      (/me nods) I get that — a lot of people feel likewise. However, I’m going to rephrase your words a little to make a point that I care about:

      “I personally don’t care whether people call the Empire State Building a skyscraper or a warehouse or a mud hut – it is still a building.”

      The statement is true, but it fails to make an important distinction between types of buildings. I hope that imperfect analogy it gets my point across; that is, that having a common vocabulary to describe things is a good thing in its own right, and that using terms too loosely leads to misunderstanding and reduced comprehension.

      • Your analogy is flawed as it is much easier to describe the differences between a skyscraper, warehouse and mud hut than it is to describe the differences between an interface pattern and an architectural pattern.

        If you cannot adequately describe the difference, then is there a difference?

        • Oh, I agree the analogy is imperfect (indeed, I said so above). And I say there are adequate descriptions of the differences (or, if you like, the distinctions) between, say, the ADR pattern and the “real original” MVC. Whether or not one chooses to recognize them, though, is another matter.

          • My point is that the description of the differences has to be enough for a newbie to understand. For example, there are some people who seem to think that SRP (Single Responsibility Principle) is different from SoC (Separation of Concerns) simply because they have separate pages in Wikipedia.

            So what exactly is the difference between an architecture pattern and an interface pattern?

  4. Probably part of the argument some would have with using or not using MVC to refer to web application architecture is defining what “application” means.

    MVC really does originate from the SmallTalk GUI world, and from other windowing systems (GUIs) such as SunView, XView and NeWS (all Sun Microsystems products), and subsequently Apple, X Windows and Microsoft Windows. In that world, MVC shines, as it’s critical to keep GUI widget states in sync with user input. Event loops rule.

    But the GUI is not an application. It’s merely used as the avenue by which the user interacts with the application.

  5. I think MVC is fine for building most things it’s used to build, but the bigger issue (which relates to what you’re saying), is that it should be “fat models, skinny controllers”, whereas the default behaviour, unless it explicitly advised against, is “skinny models, fat controllers”.

    As you said, controllers really should just be for the back and forward communication, business rules themselves should exist in the models. One problem here is a lot of MVC frameworks out of the box don’t distinguish between a model as a row in the database, and a model as the table itself–and all the business rules around it.

    But it’s pretty easy to solve a lot of the time by adding a manager layer, which sits between the controllers and the models (models as a row entities).

    Typically you’ll have one manager class for each major model, and the manager is mostly a bunch of static methods (it shouldn’t need much state), for getting and setting models in line with your business rules.

    • Agree with most of what you wrote, just that I consider your “Manager class” to be yet another model. Non persistent to database, but persistent throu hardcoding. Basically models of the business rules that connect the models of the data. It is really sad that MVC frameworks restricted people’s idea of those M, V and C concepts to specific classes.

Leave a Reply

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