Adherents to Model View Controller, knowing its origins as a graphical user interface pattern, might rationalize its validity as a pattern on the server side like so:
-
The Controller exists on the client browser. The browser receives button clicks, mouse movements, and key presses, just like in the GUI pattern. The client browser (as Controller) sends an HTTP Request event to the server when the user clicks a link, or a submits a form, etc.
-
The Model exists on the server. When the client browser (as Controller) sends an HTTP Request event to the server, the client receives back the updated Model data as an HTTP Response event. (The data may be an entire page or only a portion thereof.) This is like the GUI pattern as well, except the client is interacting with remote, instead of local, resources encapsulating business logic.
-
The View exists on the client browser. The client browser (as View), receiving the updated Model data in the form of an HTTP Response, re-renders its screen with the changes, either as an entirely new page or as changes to an existing page.
While this might be a reasonable way to describe the user interface of the client side of the network interaction, it says nothing about the user interface on the server side of that interaction.
Action Domain Responder specifically addresses the user interface components and collaborations existing on the server side.
N.b.: One correspondent suggests there is "an interesting proof that something is up with MVC in a web context" to be found when there is no browser involved, such as using
curlorwgetto interact with a server-side application that emits JSON response bodies. "The HTML message body is no more a user interface than a JSON message body---both are simply serialization formats" as far as the server is concerned.
Adherents to "Model 2" MVC may object that Action Domain Responder could be described using variations on Controller and View, instead of as a pattern of its own. For example:
-
It could be that an Action is a variation similar to Page Controller, and thus better termed Action Controller , Single Action Controller, Focused Controller, or Invokable Controller. It would thereby fit the Controller component of "Model 2" MVC. (Indeed, the formal description for Page Controller says that it represents a "page or action.")
-
Likewise, it could be that Responder is a variation similar to Template View or Transform View, and thus better termed a Response View. It would thereby fit the View portion of "Model 2" MVC.
Those alternative formulations are not as good a description of server-side components and collaborations as ADR is.
One reason has to do with the origins of MVC in graphical user interfaces, in particular the continuous interaction between many separate MVC triads in memory to notify each other of updates. On the server side, no such continuous messaging occurs. There only one interaction: that of receiving the HTTP Request, and then sending the HTTP Response in return. ADR reflects this reality: the Action invokes the Domain, then it invokes the Responder, but neither the Domain nor Responder communicate any changes to each other.
Another reason is the "Model 2" exhortation to place all processing logic in the Controller. This is a poor separation of concerns; business logic should go in the domain layer, not in the user interface layer.
It is better to make a clean break with the term MVC (with its graphical user interface history) and use a new term (ADR) specifically for server-side over-the-network request/response environments.
Some critics feel Action Domain Responder is missing some elements.
Because ADR is an HTTP-specific user interface pattern, the presence of HTTP Request and Response elements is presumed as a sine qua non.
The ADR pattern does not describe routing, dispatching, or other web handler elements. Those elements are more properly the purview of Front Controller. When it comes to ADR, a Front Controller might:
-
inspect and/or modify the HTTP Request before dispatching it to the Action,
-
inspect and/or modify the HTTP Response returned by the Action,
-
dispatch directly to a Responder without passing through an Action, in particular when there is no Domain interaction needed,
-
bypass any ADR subsystem entirely in favor of some other subsystem, such as ...
- when routing fails due to URL path, HTTP method, or other mismatches,
- when the requested content-type cannot be presented by a Responder, or
- when authentication credentials or session identifiers are not present.
This is to say that although Action Domain Responder may be one part of the request/response user interface, it may not be the entirety of the user interface.
These are some of the other patterns generally seen as refinements of, replacements for, or complements to Model View Controller. See also the pattern discussion from Derek Greer at LosTechies.
Is ADR really one of these other, pre-existing patterns, just under a different name? Here are the other patterns that have been mentioned by critics of ADR, with their similiarties and differences explained.
DCI is described as a complement to MVC, not a replacement for MVC, since it is not a user interface pattern. As such, it is fair to call it a complement to ADR as well.
EBI goes by several synonyms: hexagonal architecture, ports and adapters, and ECB (Entity-Control-Boundary). It is further described as part of a Clean Architecture by Robert Martin.
As with DCI, EBI/hexagonal/etc. is not a user interface pattern, so it too might best seen as a complement to MVC, not a replacement for MVC --- and likewise to regard it as a complement to ADR.
N.b.: "Adapter" is also called "Mediating Controller."
At first, MVA looks like it might be an exact fit for ADR. Via Stefano Borini:
Model-View-Adapter is a variation of the Triad where all communication between Model and View must flow through a Controller, instead of interacting directly as in a Traditional MVC Triad.
This fits very well the idea of an Action invoking a Domain element, then passing the result to a Responder for presentation.
But then we find this:
The Controller becomes a communication hub, accepting change notifications from Model objects and UI events from the View.
It appears MVA is still very much an in-memory GUI pattern dependent on a subject/observer system. Other articles on MVA reinforce this, both one by Palantir and the one at Wikipedia.
ADR, in contrast, is for request/response environments.
N.b.: MVP has been retired in favor of Supervising Controller and Passive View.
At first, this looks like a candidate match for ADR, especially in that the Passive View and the Model have no dependencies on each other as noted on the Passive View page. From Fowler's narrative:
Supervising Controller uses a controller both to handle input response but also to manipulate the view to handle more complex view logic ...
A Passive View handles this by reducing the behavior of the UI components to the absolute minimum by using a controller that not just handles responses to user events, but also does all the updating of the view. This allows testing to be focused on the controller with little risk of problems in the view.
Let us examine this a little more closely:
-
Model and the Domain map closely, as they do in MVC.
-
Passive View does not map well to either Action or Responder; it might better be regarded as the response that gets returned to the client.
-
Supervising Controller might map to Responder, in that it "manipulate[s] the view to handle more complex view logic." However, Responder is not responsible for interacting with the Domain, and it does not receive the client input, so does not seem to be a good fit for Supervising Controller.
-
Alternatively, Supervising Controller might map to Action, but the Action is not responsible for manipulating the view (i.e., the response).
In all, this seems a case of close-but-not-quite.
MVVM maps only incompletely to ADR.
True, the Model in MVVM maps closely to the Model in MVC and the Domain in ADR. Similarly, the View in MVVM maps closely to the View in MVC and the Responder in ADR.
However, the ViewModel does not map well to a Controller in MVC or an Action in ADR. Because ADR is a refinement of MVC, it seems reasonable to think comparisons between MVVM and MVC would apply equally well to ADR.
For an extended description of those differences, please see these articles from Joel Wenzel, Avtar Singh Sohi, Rachel Appel, and Niraj Bhatt.
In email discussions with an interested party, I was informed MVVM is just like MVC, but with an added ViewModel to intermediate between the View and Model. In that case, a ViewModel is just as useful in ADR as it would be in MVC. Perhaps ViewModel could be considered a variation on Domain Payload as used in ADR.
From the originating site:
- Models encapsulate everything that your application knows.
- Operations encapsulate everything that your application does.
- Views mediate between your application and the user.
- Events are used to join all these components together safely.
This is an interesting pattern; Models and Operations are reminiscent of to Domain-Driven Design idioms. However, I do not think MOVE is a close fit for ADR, specifically because of this paragraph:
Listening on events is what gives MOVE (and MVC) the inversion of control that you need to allow models to update views without the models being directly aware of which views they are updating.
In ADR, the Domain and the Responder do not update each other. The Domain work is completed and passed to the Responder for it to present to the client.
PAC is used as a hierarchical structure of agents, each consisting of a triad of presentation, abstraction and control parts. The agents (or triads) communicate with each other only through the control part of each triad. It also differs from MVC in that within each triad, it completely insulates the presentation (view in MVC) and the abstraction (model in MVC). This provides the option to separately multithread the model and view which can give the user experience of very short program start times, as the user interface (presentation) can be shown before the abstraction has fully initialized.
This does not fit the description of ADR very well.
RMR and ADR are very similar, and map well to each other:
Resource <--> Domain
Method <--> Action
Representation <--> Responder
However, some nuances of RMR make me think they are still somewhat different from each other. For example:
So in an OO language, a HTTP resource can be thought of as an object with private member variables and a number of public methods that correspond to the standard HTTP methods. From an MVC point of view, a resource can be thought of as a model with a bit of controller thrown in.
To me, this mixes concerns just a bit too much. I'd rather see a cleaner separation of the domain model from the action being applied to the domain.
So the representation is like a view in MVC, we give it a resource object and tell it to serialize the data into its output format.
There seems to be no allowance for other kinds of HTTP Responses, such as "Not Found." That kind of response is clearly not a representation of the requested resource.
It may be that ADR could be considered an expanded or superset variation of RMR, one where a Resource and an action one can perform on it are cleanly separated into a Domain and an Action, and where the Representation (i.e., the building of the response) is handled by a Responder.