In part 2 of this series I discussed what web frameworks are and how they worked. This post will explain architectural patterns and which among them will be used for Analyze.
Architectural Pattern or Design Pattern?
After deciding to use a solution other than MVC I began researching alternatives. During this exploration I noticed something peculiar: MVC was being referred to as both an “architectural pattern” and a “design pattern.”
“The MVC design pattern decouples these…”
From the same Wikipedia article, the next paragraph actually:
“this architecture has become popular for…”
So what gives? Are the terms used interchangeably? The Wikipedia page for each pattern doesn’t provide clarity.
“An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.”
“In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design.”
Fortunately, a kind soul known only as pyfunc answered this Stack Overflow question on November 22, 2010. His answer, in part, reads:
“Design patterns are usually associated with code level commonalities. It provides various schemes for refining and building smaller subsystems. It is usually influenced by programming language. Some patterns pale into insignificance due to language paradigms. Design patterns are medium-scale tactics that flesh out some of the structure and behavior of entities and their relationships.
While architectural patterns are seen as commonality at higher level than design patterns. Architectural patterns are high-level strategies that concerns large-scale components, the global properties and mechanisms of a system…
… If you have followed the thoughts laid above. You will see that Singleton is a “design pattern” while MVC is one of the “architectural” pattern to deal with separation of concerns.”
So Many Architectural Patterns
There are many alternatives to MVC; examples include: Model-View-Adapter, Model-View-Presenter, Model-View-ViewModel, and Presentation-Abstraction-Control. Each have a unique philosophy and approach, yet nothing piqued my interest until I came across Resource-Method-Representation.
RMR was defined by Paul James in 2008. Paul’s goal was to outline an approach for building web apps in a RESTful way. Essentially resources – for example, cupcakes – are mapped, modeled, and respond to standard HTTP methods (GET, POST, PUT, etc.). To get a cupcake with an id of 42 your route would be something like:
You may be asking: “How’s that different from any other pattern? I could make the same route in Laravel.”
That’s true, but the route isn’t the point.
With MVC you would likely have a route that pointed to a method on a controller. Sticking with the Laravel example:
The method would retrieve data from the Cupcake model and send back a response.
Using RMR a Cupcake resource would be defined. This resource would expose methods that correspond to standard HTTP methods. As such, each request is routed to the appropriate resource automatically. Explicitly defining routes wouldn’t be required. Do a GET request and you’re returned sweet Cupcake data, do a DELETE request and the Cupcake ceases to exist.
Great, so I’ll be using RMR then? Not quite, but kind of.
Action Domain Responder
ADR and RMR are quite similar. In fact, Jones notes:
“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.”
I like that. I’ll be using it in Analyze.
Last updated on August 27, 2018.