VersiĆ³n en castellano

Tuesday 14 February 2012

An alternative to traditional MVC architectures for web development

In the previous post, i pointed some incoherencies about the "traditional" way frameworks apply MVC to web development.
Now, i'll propose a slightly different architecture, hoping it'll be more natural, while solving the incoherencies of plain MVC.I'll call it "Stacked MVC", but i suppose somebody else, in some place, has already described it, and called it in some other way..Duh!..


What it's shown there are 2 MVC systems.One of them, is strictly managing the bussiness side of the system.If it's an art gallery, it manages all CUD operations, like adding an artist, adding a picture, or a comment to a picture,etc.This MVC subsystem should not know anything about HTTP variables like $_POST,$_GET,$_SERVER,$_SESSION...
The controller should be invoked with User, Request, and the parameters required to serve that request.Ideally, the existence of those parameters, the sanitization,etc, has already been done.
The "V" of this sub-system, is nothing more than datasources, in a fixed format.For example, an "artist info" view, would return this info as an array, an xml, or any other format suitable to store data.
It may have it's own, private database, storing only bussiness-related data.

What invokes those "views"? The Web subsystem.
Most frameworks try to push down to the View Layer anything that is related to HTML.But, once there, it becomes obvious that the problem is not just generate HTML.A website is more complex than just HTML.There are headers, footers, metas,sidebars, client-side scripts, css files, language/i18n files..

And somehow, all that must fit in the View layer, that, having so much responsability, must use concepts completely extraneous to MVC like 'layouts', 'helpers','snippets' and all that kind of..."scripts", to finally be able to render a page.

When it should be obvious, that what it's called "layouts", is a "controller".A "Page", a "Section",a "Header",a "Footer", a "Sidebar", are objects that exist in the context of a website, so they're Models.A web page is much more than simply a bunch of HTML.There's a logic between all the components of a web page, much like there are relations between artists and their pictures.
To render bussiness subsystem data, the website subsystem uses the previously mentioned datasources, the same way it uses a database;The "model" objects in the website subsystem ("Section"), "queries" the bussiness subsystem to fetch the data it requires, and sends it to a certain "Section View".

Any "R" request arriving at the web server, is sent to the website subsystem.
Any "CUD" request, is sent to the bussiness subsystem, and, if that request is configured to generate a "R" request after the bussiness subsystem has processed it (onError, onSuccess), adds to the famous tuple of $_POST and $_GET, information about the result of the processing done.

This is just a quick intro to this idea.There are more advantages, gotchas, and ideas around it.But, to finish this intro, i'd like to say that i'm not trying to say we need MORE frameworks (O-M-G)..This architecture is more about having a guideline on how to distribute the application code, than using (insert bloated framework name here) to solve it all.

No comments:

Post a Comment