My distorted view of MVC

[rainmotorsports]

I have been porting a procedural application to ...not sure I can actually call it MVC. Since I am still only a step past my front controller, I have read up on alternatives. The entire point of the move is to abstract everything into easy to maintain code.

Given the stateless nature of HTTP. A lot of these alternatives seem like terrible attempts when applied to PHP at changing that for the application. The rest seem to be no different than random developers takes on implementing MVC.

From my view point a user makes a request, that request is handled in code. At some point the code interacts with the database. The code eventually returns the view. MVC as I have done it gets off on the wrong foot since the users first action starts at the Controller. Shouldn't it be CMV? I guess by the time the concept made its way to stateless web development, abstract portions of the concept were no longer exact.

I abstract my main code out to the "controllers", the data handling to the "model", the "view" is passed relevant variables and handles rendering the templates. Am I crazy or what concept does this best fit under?

 

[Xon]

XenForo doesn't use classical MVC, but something closer to Model-view-adapter or model-view-presenter. In both cases; View <-> Controller <-> Model, rather than the MVC triangle of the model directly updating the View.

In either case, the "model" actually means "domain model" which is more than simple data loading but includes fundamental business/domain logic.

Xenforo 2 allows the "model" to directly communicate with the View via allowing live php-objects to be passed to the view, but for sanity's sake you shouldn't be doing heavily lifting there.

 

[Jaxel]

I have no idea what any of these terms mean... Lol. I'm not a classically trained programmer. I learned by looking at other people's code and fiddling with it. So I write my xenforo add-ons to for whatever standard xenforo already uses.