Feedback

[codeguy]

Some quick feedback.

• ADR seems like it represents the simplification and specialization of web app development much like the shift from monolithic frameworks to smaller, more nimble microframework architectures. And just like frameworks <--> microframeworks, ADR is not a panacea, but more a "right tool for the job" kind of thing. Frameworks are still useful, but sometimes a micro-framework is all you need. Don't overengineer an MVC solution when a simpler ADR architecture will suffice. As you said, this seems to better represent what we developers are doing on a daily basis as we target smaller, more specific tasks.
• Letting the HTTP response become the View is a more appropriate depiction of the modern, API-driven web application.

I would like to see more clarification on this point:

The Action interacts with the Domain in the same way a Controller interacts with a Model, but does not interact with a View or template system. It sets data on the Responder and hands over control to it.

Slim uses a View class to generate output that the Action/Controller sends to the Responder/Response. For Slim, the Responder is very much a wrapper around an HTTP response. It is not required to use a View with Slim, but it does help implement third-party templating systems to help generate the responder/response body. Could this responsibility be merged into the Responder? Perhaps, but I feel like that would violate separation of concerns and make the Responder overcomplicated. Or maybe your concept of a "responder" is more a sub-system/group of components and not a single component? Or maybe we should not liken templating systems with the term "View"?

[pmjones]

Hey @codeguy, thanks for this. I know you're busy and I appreciate your time.

Regarding "simplification and specialization" --- Definitely a specialization, but I wouldn't say simplification. My impression from the macro-framework guys who have responded has been that appears to be just as applicable in their arena. As such, "Don't overengineer an MVC solution when a simpler ADR architecture will suffice" might be a misapprehension; ADR maps pretty well to MVC, with the caveats noted in the original article (single-action classes/closures, and "views" that represent the entire response, not just a template body content).

Regarding "Letting the HTTP response become the View is a more appropriate depiction of the modern, API-driven web application." --- totally, dude. I think it's more appropriate even for non-API stuff. In personal conversations, I'm using the phrase "The view is not the template; the view is the response."

Regarding "For Slim, the Responder is very much a wrapper around an HTTP response. ... it does help implement third-party templating systems to help generate the responder/response body. Could this responsibility be merged into the Responder?" --- Perhaps my description is not clear enough on this point; the Responder handles both headers and body, and can do so in any way it likes, including the use of a Template View or Two Step View (or other View) system. (EDIT: So yes, you are correct, the Responder can use a collection of components to fulfill its duties.)

Does that help to explain at all? Do you feel other language is necessary to clarify these points in the main narrative?