Matt SparksIn part 2 of this series I discussed what web frameworks are and, in (very) broad terms, how they worked. Now it’s time to take the first step toward actually building a framework.
Architectural Pattern or Design Pattern?
Near the end of the last installment I mentioned that I had decided to use an architectural pattern other than MVC. This wasn’t a slight against MVC, I just wanted to try a different approach. To that end, I’ve researched alternatives to MVC along with their pro’s and con’s.
I won’t be going into detail on every pattern, but during my research I noticed something peculiar (at least to me anyway): MVC was continually being referred to as both an “architectural pattern” and a “design pattern.” From Wikipedia:
“The MVC design pattern decouples these…”
From the same Wikipedia article, the next paragraph actually:
“this architecture has become popular for…”
So what gives?
Is this one of those scenarios where all design patterns are architectural patterns but not all architectural patterns are design patterns?
Maybe people just use the terms interchangeably?
In an effort to further confuse myself I read both pattern’s Wikipedia page. Here’s the first sentence of the “Architectural pattern” page:
“An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.”
Here’s “Design pattern”:
“In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design.”
Alright, that didn’t really help.
Fortunately, a kind soul known only as pyfunc, answered a Stack Overflow question on November 22, 2010. His answer, in part:
“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.”
MVC is an architectural pattern, not a design pattern! A lot of other people agree with that assessment, too. Am I saying Wikipedia is wrong? Well, I’m not saying they’re right.
So Many Architectural Patterns
With that mess sorted, let’s get back to the task at hand.
I won’t be using the MVC pattern for Analyze. To decide what to use instead I researched the many alternatives. I looked through a bunch of MVC derivations: Model-View-Adapter, Model-View-Presenter, Model-View-ViewModel. I read about Presentation-Abstraction-Control, Presenter first, and dozens of others. Nothing really piqued my interest until I came across Resource-Method-Representation.
RMR was defined by Paul James back in 2008. His goal was to outline a way to build web apps in a RESTful way. Essentially, resources – say, for example, cupcakes – are mapped, modeled, and respond to standard HTTP methods (GET, POST, PUT, etc.). So, to get a cupcake with an id of 42 your route would be something like:
GET http://example.com/cupcakes/42
I bet you’re asking, “So how’s that different from any other pattern? In Laravel I could make the same route.”
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:
Route::get(‘cupcakes/{id}', ‘CupcakeController@index’);
From there the method would pull in data from the Cupcake model and ultimately send back a response of some sort.
RMR would argue that this isn’t the best approach to expose resources. In RMR, you would have a Cupcake resource with methods that correspond to standard HTTP methods. Each request is routed to that resource pretty much automatically since it would map directly to whatever HTTP method is used. 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
While digging into RMR I stumbled across Action-Domain-Responder, created by another Paul, this time of of “M Jones” variety.
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 want to have a greater knowledge and understanding of ADR, so I’ll be using it in Analyze.
In the next post, code will be written.
