PHP MVC Best Practices/"Rules" for Success

Question

I'm sure that someone already posted this question; however, I would like to get all kind of recommendations for MVC on PHP. I know there are many experts out there willing to share their knowledge with people who has doubts about their coding best practices.

• How should you organize your Controller?
• How should you organize your Model?
• Should Controller call one Model Method and the Model call submethods or should controller call all Model Submethods?
• etc.

Hope this helps someone out there (because it'll help me for sure).

Answer 1

I'm not sure what you mean by "organize".

The controller calls on whatever model[s] it needs in order to get the information to pass to the view[s]. It (the controller) can make multiple calls to the model for different pieces of information.

Try reading this: http://www.phpwact.org/pattern/model_view_controller

Answer 2

For php, I like to use the CodeIgniter framework. It lays the ground work for the MVC set up. The controllers are held in "/controllers" and models are in "/models"

I believe that a controller should call the model and the model should encapsulate as much as it can, using submethods if needed. This makes your code much more adaptive and flexible. Example, today your model is reading from a local database, tomorrow you could be reading from a REST service. The model should return data to the controller and the controller should be naive to what is going on inside of the the model.

Answer 3

I might as well mention Zend. Be sure to read the linked page before posting that zend is not MVC.

Answer 4

MVC is the most misunderstood design pattern. There is by definition one model.

When an urban planner proposes a project, he designs one model for it. The separate entities that the model might be comprised of: buildings, streets, parks, are typically not represented by separate models: they are all facets of the single model.

So in MVC, the model can be comprised of different entities, and that is probably the best word for it: entity, as in an entity represented by a database table. The model in MVC might even be something more abstract than is actually represented in code, but rather a conceptual umbrella for all of the data that the application might need to act upon.

Considering this, if these entities have their own methods, notably methods that might correspond to the facets of CRUD (create, read, update, delete), they should not be exposed directly to the controller, it is too low a level of abstraction. These building blocks should be built up into a coarser grained interface, for instance you might delete a record but then return the list of records after the deletion. The controller just needs access to a coarser grained method that performs all of the above.

Furthermore, to expose the methods of the entities directly to the controller, could cause the controllers to have to be rewritten, along with the entity classes, if there is a change for instance as to what ORM (object relational mapping) system is being used. The intermediate layer I'm suggesting also is a good place for exception handling, logging and any other such administrivia that needs tending to.

The suggested layer of methods at a higher level of abstraction is sometimes referred to as the business delegate, or a "facade", but this is what I actually consider the model. Hope this isn't too theoretical, and is helpful to the OP or other readers.