MVC models in PHP - Correct process order and separation

I need help clarifying the correct structure and process flow for an MVC application in PHP.

I think I've got the concept round the wrong way because currently most of my processing is done (or at least initiated by) the Vi开发者_JAVA技巧ews. -- I kind of inherited this way of thinking from the company I'm working for, but now I'm not sure that they are understanding the MVC model correctly!

Having looked at it again I think that the proccess should be as follows (very basicly):

• The users actions are sent to the Controller
• The Controller process those actions using any Models required
• The Controller then instantiates the relevent View and passes the required data to it
• The View renders the page to the user

---

I'm also having some difficulty deciding wether the view should even have any real functionality in it or not.

i.e. Is it just a wrapper to hold the page data and load the required template files (header, page, footer etc.), OR should any functions to do with rendering data (i.e. preparing HTML and outputting HTML) be in the View?

---

Another question is does the controller 'hand over' to the model and have nothing to do with the actual DBconn (so that the Model acts like a Bouncer on the doors of the DB nightclub, and we're not on the list) OR does the controller 'own' the DBconn and simply lends it to a model when it needs it?

I'd really appreciate any help and advice anyone can offer.

Thanks

edit -- I found this helpful!

---

I'll answyer to your two last questions:

1) The Views should have basic output capabilities, for example escaping values to avoid security issues or display a html table starting from a list of objects. Another responsibility could be the translation of labels and other constant values (for example you could have $this->_('Your label') where function _($val) is a function included in all your view classes that translates the strings starting from a csv file).

2) Depending on the complexity application, you could have two sub-layers in the model layer. The upper layer is the classic model with the functionality of your entities. The lower level is the resource model class associated that performs the db operations. You could also have a single layer with your models that implements the DAO pattern. Anyway, the controller shouldn't have nothing to do with db connection.

---

Your bulleted assumptions are correct :). The main idea behind MVC is loose-coupling and interchangeability between components.

To answer your questions:

The view should be presentational only, so iterating through a list of models in the view and outputting them there is fine, but processing data in the view is not.

The model should not assume anything about the controller and the view. It should be easy for you to switch between a model that draws data from a database to one that draws data from another type of data source and this should not determine changes in the Controller. Fabrizio is right, you should check out the DAO pattern for an example on how to do this.

I really recommend taking a look at frameworks that implement MVC to see how they do it. Especially Spring - even if you're not a Java person, the implementation is very clean -, Rails, Symfony. For something more exotic take a look at Django.