Action–domain–responder

Action–domain–responder (ADR) is a software architectural pattern that was proposed by Paul M. Jones[1] as a refinement of Model–view–controller (MVC) that is better suited for web applications. ADR was devised to match the request-response flow of HTTP communications more closely than MVC, which was originally designed for desktop software applications. Similar to MVC, the pattern is divided into three parts.

Components
  • The action takes HTTP requests (URLs and their methods) and uses that input to interact with the domain, after which it passes the domain's output to one and only one responder.
  • The domain can modify state, interacting with storage and/or manipulating data as needed. It contains the business logic.
  • The responder builds the entire HTTP response from the domain's output which is given to it by the action.

Comparison to MVC

ADR should not be mistaken for a renaming of MVC; however, some similarities do exist.

  • The MVC model is very similar to the ADR domain. The difference is in behavior: in MVC, the view can send information to or modify the model, whereas in ADR, the domain only receives information from the action, not the responder.
  • In web-centric MVC, the view is merely used by the controller to generate the content of a response, which the controller could then manipulate before sending as output. In ADR, execution control passes to the responder after the action finishes interacting with the domain, and thus the responder is entirely responsible for generating all output. The responder can then use any view or template system that it needs to.
  • MVC controllers usually contain several methods that, when combined in a single class, require additional logic to handle properly, like pre- and post-action hooks. Each ADR action, however, is represented by separate classes or closures. In terms of behavior, the action interacts with the domain in the same way that the MVC controller interacts with the model, except that the action does not then interact with a view or template system, but rather passes control to the responder which handles that.
gollark: Definitely a very useful innovation despite its limitations.
gollark: It's not great compared to PC, since the vendor can just not provide updates for the vendor stuff, and the kernel is annoying, but you can update much of userspace independently.
gollark: There's a UBPorts GSI.
gollark: Oh, a decent amount, they can use the APIs.
gollark: VoLTE does *not*, and neither does FM radio for some reason, but basically everything else works fine on sane devices.

References
  1. "Action-Domain-Responder: A Tentative MVC Refinement". paul-m-jones.com.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.