Adherents to Model View Controller, knowing its origins as graphical user interface pattern, may rationalize its validity as a pattern on the web 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
wgetto 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 , Focused Controller, or Invokable Controller. It would thereby fit the Controller component of "Model 2" MVC. (Indeed, the formal description for Page Controller says it represents a "page or action.")
Those alternative formulations are not as good of a description of web-based interactions as ADR.
One reason is the origins of MVC in graphical user interfaces, in particular the continuous interaction between many small MVC triads in memory to notify each other of updates. In ADR, no such continuous messaging occurs; the Action invokes the Domain, then it invokes the Responder, but neither the Domain nor Responder communicate any changes to each other. Also, there is only one interaction, that of receiving the HTTP request and then sending the HTTP response in return.
Another reason is the "Model 2" exhortation to place all processing logic in the Controller. This strikes me as a poor separation of concerns; business logic should go in a domain layer, not in a user interface component.
It is better to make a clean break with the term MVC (with its graphical user interface history) and use a new term (ADR) which is specifically for server-side over-the-network request/response environments.
Some critics feel Action Domain Responder is missing some elements.
HTTP Request and Response
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
- when routing fails due to URL path, HTTP method, or other mismatches
- when the requested content-type cannot be presented by a Responder
- when authentication credentials or session identifiers are not present, among other things.
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 mentioned by critics of ADR, with their similarities and differences explained.
Entity Boundary Interactor
EBI is in part an alternative to MVC where the core application elements and behaviors, represented by Interactor and Entity objects, are separated from the incoming and outgoing data streams by a Boundary. This has the effect of cleanly separating the application itself from the details of the input and output mechanisms, so the core behaviors are never dependent on any particular element of the receiving and delivery systems. There is a great deal more to EBI architectures, such as use cases and roles.
I confess to being unfamiliar with EBI, and so that description may be incorrect in whole or in part. It occurs to me from my limited reading EBI may better describe domain interactions rather than MVC architectural patterns. If the above description is accurate, it appears that ADR maps only roughly to EBI:
The ADR Action and Responder elements may represent a web-specific EBI Boundary.
The ADR Domain element may represent an EBI Interactor element, encapsulating or otherwise hiding the EBI Entity elements from the ADR Action.
Alternatively, in ports-and-adapters or hexagonal architecture terms, it may be reasonable to think of the Action as a port through which an EBI Boundary is invoked as part of the ADR Domain. Finally, the Responder could be seen as an adapter back through which the application data is returned.
Regardless, it does not appear ADR is a direct replacement for EBI. It seems more likely that they are complements to each other.
Data Context Interaction
DCI is described as a complement to MVC, not a replacement for MVC. I think it is fair to call it a complement to ADR as well.
Model View Adapter
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.
ADR, in contrast, is for request/response environments.
Model View Presenter
At first, this seems 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.
Model View ViewModel
MVVM seems to map only incompletely to ADR. 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.
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. If this is true, then a ViewModel is just as useful in ADR as it would be in MVC. Perhaps this could be considered a variation on Domain Payload as used in ADR.
Models Operations Views Events
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 in itself. The idea of Models and Operations seems to map well 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.
Presentation Abstraction Control
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 seem to fit the description of ADR very well.
Resource Method Representation
RMR and ADR seem very similar, and seem to 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 seems like mixing 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.
There are hints of ADR, especially the Responder element, in Separated Presentation. Although the article is well worth reading, Separated Presentation sounds more like a meta-pattern that describes the general concern of separating data from presentation, not a specific approach to doing so.