MVC and ADR are User-Interface Patterns, Not Application Architectures

N.b.: I am the author of the Action-Domain-Responder paper referenced in this article.

In his post on MVC alternatives (including Action-Domain-Responder), Anthony Ferrara makes a claim that is central to his discussion. While I agree with much he says in that and related articles, I believe that one claim is in error, and while it does not discredit the essay as a whole, replacing the erroneous claim with a more accurate one gives the essay a different flavor.

The central mistake I think Anthony makes is near the end of this post, where he states (in talking about MVC, ADR, et al.) that “All Pretend To Be Application Architectures.” That assertion strikes me as incorrect.

While it may be that developers using MVC may mistakenly think of MVC as an application architecture, the pattern description itself makes no such claim. Indeed, Fowler categorizes MVC as a “Web Presentation Pattern” and not as an “Application Architecture” per se.

Sure, MVC is described in book called “Patterns of Enterprise Application Architecture”, but MVC itself is a presentation pattern within an application architecture. Here’s another example of the distinction: we would not call “Table Data Gateway” an application architecture, even though it too appears in the same book. It is a data source pattern within an application architecture.

Fowler’s categorization and description of MVC define it pretty clearly as a user interface pattern. ADR, as a refinement of MVC, is likewise a user interface pattern. Neither is an application architecture in and of itself, although they are the outermost part of an application architecture. So when Anthony’s article states elsewhere that ADR’s “coupling to HTTP that it becomes difficult to make a non-HTTP interface” my response is “Well, obviously – it’s a user interface pattern centered around HTTP.”

Anthony then goes on to say:

And that’s the biggest reason all of these “patterns”, “architectures” and “concepts” are a bad joke. They solve the easy problem, and throw the hard problem over the fence.

MVC, ADR, et al., solve a user-interface problem. That may be an easy problem for Anthony to solve, but to say that user-interface patterns “throw the hard problem over the fence” strikes me as starting from the wrong set of expectations. MVC and ADR, as user-interface patterns, aren’t supposed to be dealing with core business logic in the first place.

It might be better to say that the underlying application that is presented through the user interface is not really the user interface’s problem in the first place. The user interface code probably should not care too much about the internal operation of the underlying application code. If it does, then the application code is bubbling up too far into the user interface.

In summary, I think the assertion that “All Pretend To Be Application Architectures” is just not an accurate categorization. It would more correct to say that “All Are User Interface Patterns, Not Entire Application Architectures” – or, even better, that “Developers Frequently Misunderstand Them To Be Application Architectures”.

Are you stuck with a legacy PHP application? Subscribe to "Modernizing Legacy Applications in PHP" for tips, tools, and techniques that can help you improve your codebase and your work life!

Share This!Share on Google+Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedIn

10 thoughts on “MVC and ADR are User-Interface Patterns, Not Application Architectures

  1. currently MVC is used mostly on the user side, but it used to decribe a whole application architecture. This days you ususually have something similar to MVC on the server side with some extra layers like DAO, DTO… On the user side you can have some more layers that resamble MVC (e.g. ExtJS). But still if you treat server side code separatly (as SaS) and user side as a simple consumer, then MVC is describing whole application architecture. MVC is very general to that I would agree but still descrbes everything that happens in the application.

  2. Why can’t MVC be considered as *BOTH* a UI pattern as well as an application architecture? The 3-Tier Architecture is most definitely an architecture, and MVC can be considered to be a variation of this. In fact, it is possible to combine the two into a composite architecture as described in

    Personally I find this type of argument – is it a pattern or is it an architecture – to be nothing more than nit-picking over irrelevant trivialities and therefore a complete waste of time.

    • @Tony Marston: because clearly when it is treated as an architecture it becomes an awkward fit due to the reasons presented by Anthony Ferrara.

      “Good” developers recognise very quickly that MVC in the context it is presented by Rails and it’s ports/inspirations/derived works breaks down when you attempt to build anything that beyond a trivial application because you are attempting to fit a square peg into a round hole. By recognising where MVC comes from (the canonical “Smalltalk” MVC) you can improve the relevance of the pattern to your application and not run into the issues relating to putting the wrong thing in the wrong place.

      If you consider MVC (or any pattern for that matter) to be your application architecture you are in for a bad time because no one architecture fits all problems. In fact in all my years of developing software using a variety of “MVC” frameworks not once have I used the same architecture. The architecture should be determined by your problem, not the tools you chose to use.

      MVC (and it’s derived patterns) are useful for describing a particular type of solution and Paul rightly points out what it is that they are trying to point out. And no, MVC is not considered a variation of 3-Tier (or N-Tier) architecture. MVC is a User Interface Pattern. It describes a model (which is analogous to the domain in the ADR pattern if I am not mistaken, and not the “data access layer” in an N-Tier application, although the domain layer may contain a data access layer if that is appropriate for the application) which houses business logic, a controller which marshals requests and generates appropriate responses and a view which represents the state of the model to the user. That’s it. Nothing more. It is fairly clear that this is not sufficient for describing an entire application – the architecture of the domain isn’t even touched upon.

      The argument isn’t “is it a pattern or is it an architecture” isn’t even the argument being made here. The argument being made here is that MVC is not a pattern for wholesale application architecture, and instead only describes one part of a potential application’s architecture – the user interface (or presentation layer).

Leave a Reply

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