Allow me to point that in PHP there is no such thing as 'mvc'. MVC in the classical sense is not possible because of the request -> response -> dead cycle. You need to get out of your head that you're doing anything like MVC because there's no bi-directional communication between the model updating the view automatically. You're more likely doing something along the lines of MVP. What you can aim for, though, is the separation of concerns.
The problem with Model-View-Controller is that it's so open to abuse (and also opinion) that it's incredibly hard to get 'correct' from one developer's view to another, and that's without even throwing in the fact that simply putting code into a class does not make it "Objected Oriented Programming".
Symfony2 doesn't claim to be "MVC" more than a few times for the previous reason. It's a great framework, but utilises poor design concepts like the service locator pattern (an anti-pattern; ooh controversial) which hides class dependencies.
CakePHP and CodeIngiter are well known for being easy to get into - hence you get a lot of bad practice and poorly written applications from them.
If you want to just use a framework and get on with it, Symfony2 is a great choice. If you want more of a say in your application architecture, take a look at Silex.
Now, as for the "how" of doing MVC in PHP, here's one way of going about it.
Front Controller / Bootstrap
You utilise a front controller (maybe using a .htaccess) to take all requests through. From the request, you can do multiple things - depending on your level of abstraction you may have a
Request object or you're just using plain old
Here you bootstrap your required files and then you pass your data to the router.
Oh, and you'll also need an autoloader that knows exactly where to look for your files when you ask for them. PSR-0 is a good standard to follow here and includes the code for a basic PSR-compliant autoloader.
Your router's job is to route the request to the appropriate Controller / Action. For example:
application/login will have the router route to the
login controller, and (as no action is specified) the index action (this is entirely up to you how you code it).
You can even utilise regex (like Symfony2 does) to figure the correct route for your request.
You'll typically then instantiate an instance of the controller class, then run the action on it by executing the method.
You're in your controller. This is where things get complex, not easy. If you want to use GOOD OOP, don't hide class dependencies. This means you should pass the controller dependencies into the class, maybe using reflection to perform recursive object instantiation. Auryn is a brilliant example of this.
Regardless of whether or not you want to follow good practice, your controller is where you make requests to the model layer to retrieve data.
Your model is a layer, hence it is not pluralised. You can view what the model layer does here. In short, the layer consists of:
- Domain Objects
- Data Mappers
These perform your business logic, as abstracted as you want, and return that data to the controller that requested it.
Finally, you shove this data in a view and render the relevant template (via
The view goes even further here; you have views and templates, which are not the same, but that's the extent of my knowledge and, for all intents and purposes, simply including the relevant file with the required variables to display has been fine for me.