Stephan Hochdörfer and Action-Domain-Responder

I’ve been asking for feedback on the Action-Domain-Responder pattern, a refinement of MVC, to discover how it’s being used in the wild already, and to solicit criticism of the pattern to find weak points.

The key points of Action-Domain-Responder:

  • Instead of a controller class with many action methods, each Action is its own class (or closure, like with Slim).

  • The Action interacts with the Domain (model), and feeds data to a Responder (view).

  • The Responder is entirely responsible for building the response, including all headers as well as the body of the response. This means that in ADR, the template is not the view; the response is the view.

Stephan Höchdorfer has been using single-Action classes for a while now. Here is my summary of his article:

  • “we are using action classes in our application framework for almost the last decade”

  • “action classes tend to be rather small, typically less than 100 loc for us”

  • “another bonus point for action classes: It is easier to search for a class name than a method name”

  • “Controllers tend to have a lot of dependencies. … people came up with a few “creative” solutions for this problem, mainly the creation of lazly loaded dependencies”

  • “action classes depend on what they really needed. Typically that’s just a few services for a single action. Again that makes the code way easier to understand and easier to test.”

  • “Action classes in contrast to controller classes can be reusable.”

Those were the highlights for me; you should read the whole essay to find your own:

In addition, please write up your own commands and criticism regarding Action-Domain-Responder, so that I can improve the offering as much as possible.

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.

2 thoughts on “Stephan Hochdörfer and Action-Domain-Responder

  1. Where I work we use completely separate classes for actions (where action is defined as something that modifies data). An action is named (i.e. AddComment), selected by a request value (?action=AddComment) and either redirects after it saves its response to session flash message queue, or – usually on failure – passes control back to the usual controller stack to display the offending form again. The main point is that we separate actions from the presentation classes so that a request like “/post/12?action=AddComment” first executes the action, and only then passes on to execute the controller to display content and response messages (if any).

    As a note our main controller uses a view configuration to execute a bunch of sub-controllers, one for every separate page element, like a menu, or a sidebar box. Each sub-controller has its own data sources, accesses request data and renders its content as a separate entity. This allows for a more flexible composition of content elements on every view.

    I’ve never seen a system like that before, and I find it quite useful in some ways.

  2. Pies,

    It sounds like your company uses a customized version of HMVC, Hierarchical MVC, based on your second paragraph’s mention of sub-controllers for each element. The split between processing actions and presentational code is a nice addition, in my opinion.


    I’ve been thinking about something similar to ADR for almost 9 months now, and I’m encouraged to see I’m not the only one thinking along these lines. I wish I could say that I’ve been doing it in the wild, but it’s all been conceptual at this point.

    One of the potential cons you’ve listed I just don’t think will exist, in the long run. And that is “more classes”. Much of the administration-side of applications can be abstracted into a small set of actions like “CreateEntity”, “UpdateEntity”, and then executed using services configured by dependency injection and route-based configuration. Barely anything changes between processing of POST actions, except for services and which repository to use, so it could be quite slim. Perhaps the same could be done for responses in APIs, one responder class per data type rather than one per model.

Leave a Reply

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