I have been reading and researching about MVC, HMVC, PAC and MVVM design patterns and have also seen a few so-called implementations of MVC and HMVC.
This question is NOT about difference in these design patterns, I just want any expert who understands these design patterns and their implementations in apps/frameworks working in stateless enviornment (PHP on a web server) to categorize my approach.
I will use references from wikipedia and an article I read written by larry garfield on MVC vs PAC
One of the most common mistakes I see people make when talking about
web architecture is with regards to MVC. Generally it comes down to a
statement such as this:
It's a web app, so we have to use MVC. That way we separate the logic and presentation, which means keeping PHP out of our display layer. All the important projects do it that way.
Of course, such a statement is false. It demonstrates a lack of
understanding about MVC, about web applications, about "important
projects", and about software architecture in general.
My implementation:
I have controllers and models classes while I am using a template engine to handle views so views don't have their own classes per se
It all starts with a front controller which reads the http request (RESTfuly) and routes request to the relevant controller by instantiating it and then calling relevant method according to request (i.e. postSomething() or deleteThat() etc...) however if a input method is GET then a "view" method is called which tells template engine to parse its template file. (Output depends on http accept header for all methods and controller method is determined by params coming with request, etc.. etc... but what's important here that my controllers optionally have single view method for GET requests which processes HTML templates.
My models are mostly ORM layers (combination of data mapping and active records) and other sorts of abstractions
While this all works pretty well for me, and I am very much satisfied with benchmarking and everything, I am just curious how should I classify this design pattern
Why its not MVC or one of its variant (MVP, MVVM)?
In MVC, the View component has direct access to the Model. The Controller itself doesn't enter the picture unless there is actual change to the data. Simply reading and displaying data is done entirely by the View component itself.
...
On the flipside, however, that means the View component has to have some rather complex logic in it. It needs to know how to pull data out of the Model, which means it needs to know what the data structure is (or at least a rich API in front of the Model). It needs to be able to handle user interaction itself, with its own event loop.
Unlike MVC, all the intelligence in my implementation resides in controllers. Controllers manipulate data via models and then serve output or call view method. Controllers may also call other sibling methods (methods with in same controller class). Also my views (method) and models never interact with each other.
Also in most of the resources I have found that in actual, MVC/MVP and MVVM design patterns, input starts with views not controllers which is opposite of my implementation. (However frameworks that I have seen implementing MVC/HMVC, their flowchart starts with controllers receving input, which contradicts MVC)
MVC/MVP/MVVM flowchart
What about hierarchy?
In my implementation, my app has 2 interfaces, "frontend" and "backend" (operates on a different http port). Both of these interfaces have their own controllers and views (template files) while both use same models/abstractions.
models/
Frontend/
controllers/
views/
Backend
controllers/
views/
Inside the interface, a controller can dispatch sub-requests to other controllers in same interface (or another) to form a main response/output but there is NO as such directory architecture:
Frontend/
module1/
controllers/
models/
views/
module2/
controllers/
models/
views/
Is it PAC? but how much?
The two main differences between MVC and PAC are that in PAC the Presentation component is "dumb" while all the intelligence resides in the Controller and PAC is layered. Again, see the pretty picture.
You'll notice that the Presentation and Abstraction components never speak to each other. The Controller takes input, not the display component. The Controller has all the business logic and routing information. The Presentation component is essentially just a filter that takes raw data that the Controller pushes through it and renders it to HTML (or WML, or XML, or text, or an icon in a graphical monitoring system, or whatever). It's just a templating system.
and... from wikipedia:
In contrast to MVC, PAC is used as a hierarchical structure of agents, each consisting of a triad of presentation, abstraction and control parts. The agents (or triads) communicate with each other only through the control part of each triad. It also differs from MVC in that within each triad, it completely insulates the presentation (view in MVC) and the abstraction (model in MVC).
so basically my implementation sounds more like PAC (at least flow and handling of request matches it) but does my implementation matches PAC hierarchical wise?
Also please explain this line "It also differs from MVC in that within each triad, it completely insulates the presentation (view in MVC) and the abstraction (model in MVC)."
does it mean that in PAC, a triad cannot access models and views of other triad or does it mean that in MVC models and views can interact it with eachother while in PAC they cannot.
But if so, doesn't it make most of the frameworks out there claiming to be MVC or HMVC, in fact PAC based?