There\'s around a zillion \"PHP frameworks\". And most of them bill themselves a

Question

There's around a zillion "PHP frameworks". And most of them bill themselves as following the MVC pattern. While it's welcome to overcome osCommerce coding style (processing logic heavily intermixed with SQL and HTML), there are certainly simpler and easier to follow approaches to get a maintainable application design.

The original MVC concept was targetted at GUI applications. And for Gtk/Python it seems feasible to follow it accordingly. But PHP web apps don't operate on live Views (GUI elements) and a persistent Controller runtime. It's quite certainly a misnomer if it just describes the used code + directory grouping or class naming.

"MVC" seems to be used like a buzzword for PHP frameworks. And I've actually seen one or two mature PHP frameworks admit it, but redefining the phrase anyway to match interna.
So is it generally snake oil? Why isn't better terminology used, and a more sensible concept for maintainable PHP propagated?

Some elaborative reasoning

Why I suspect that PHP implementations don't follow the real MVC pattern:

Models: in theory, Models should be fat and contain business logic, and controllers should be thin handlers (input->output). In reality the PHP frameworks advocate shallow Models. CI and Symfony for example equate Model == ORM. Even HTTP input is handled by the controller, isn't treated as model.

Views: workarounds with AJAX discounted, there can't be Views on web pages. PHP frameworks still pump out pages. The interface still effectively follows the ordinary HTTP model, there's no advantage over non-MVC applications. (And lastly, none of the widespread php frameworks can factually output to GUI Views instead of HTML. I've seen a PHP library that can operate Gtk/Console/Web, but the frameworks don't.)

Controller: I'm unsure. Controllers probably don't need to be long-running and persistently active in the MVC model. In PHP framework context, they're however mostly request handlers. Not really something to get argumentative about, but it just feels slightly buzzwordish.

Would there be better descriptors? I've seen acronyms like PMVC or HMVC thrown around. Though descriptions get more ambigous there, maybe these would describe the current web frameworks less hokey?

Explanation / Answer

I think you are looking at this in completely the wrong way. A GUI app and a web page are worlds apart so the exact same definition of MVC will never work for both. MVC is more about the ideal: separating certain parts of the app like display and logic.

In PHP (or the web in general), a View is the web page itself: the HTML output. It's not "live" as per your definition, but you simply click links to go back to the controller (i.e. another page request).

The Controller and Model is where things do differ, like you explained. In PHP the model tends to be the data layer, interacting with the database and so on. But it is still modelling the situation, and the controller still controls the application flow, if only once per page load.

So the name "Model-View-Controller" is perfectly logical, albeit a different implementation in GUI apps vs web apps.

Related Questions

Navigate

• Browse (All)
• Browse T
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.