PHP MVC - How to design?

I'm relatively well versed in designing websites. I mostly go for LAMP where I already have a small "framework" of my own, that I use. In short, it separates the logic from the layout and I have basically one logic file to one or many layout files depending on what views are supported in the layout. There's an admin section and there are user auth and all such stuff. Fine.

So, when looking to get more elaborate in my way of designing / programming in PHP - or website programming at large - I'm wondering how to "think" MVC properly. I'm leaning towards this way since my current framework is very DB oriented and has become somewhat heavy where performance is of the essence.

So here's my question: Am I correct in assuming that a controller typically corresponds to a "section" or "page" and a view takes care of displaying that controller, and that a model handles the objects used by the controller and being displayed in the views?

Let's take an example (not too elaborate, but enough to see if my thinking is valid):

Say we have a simple games website. The sections would typically be something like: frontpage, games, forums, and about / disclaimers etc.

The controller classes corresponds to the sections but gets a little more elaborate to cover the "single instance" version of the object covered by the section i.e. games section becomes two controllers; one for games overview (list of games) and one for the game page itself. The whole would be something like frontpage, games-overview, gamepage, forums, forum, topic-page, about, and disclaimer.

The views can be a number of layouts for each controller e.g. the same as the controllers but perhaps various types of views on the forums pages (depending on how you want to view them) and games pages (maybe a highscore view) and so on.

The model (or dataobjects) are typically users, games, forums, topics, posts, and then a lot of helper objects like topic tags, game highscores and what not to make the topics possible to categorize and the games able to have highscores etc etc.

Is the above "correct" way of thinking or am I totally misunderstanding the whole M-V-C concept for开发者_StackOverflow社区 websites.

I'm thinking about moving over to CodeIgniter or some other light framework (feel free to comment on framework choice or if it is better to go for my own) since my own framework is very DB-oriented and is not cutting it now that a couple of my sites are surpassing 70,000 pageviews / day.

A sincere thank you to those of you who can help in answer whether or not my take on MVC is somewhat correct and also if possible, add a few hints of what to think about when coding MVC and still want to maintain cutting edge performance (as much that is possible with scripted languages).

First of all, this is not a php specific question but rather a question about how to apply the MVC pattern to web programming. And indeed the MVC pattern makes so much sense in the area of web application development that it has almost become an imperative in this field of application.

Now, as for the MVC pattern itself, you will find very good answers on SO already. For example the Question and Answers of What goes into the controller.

As for the question of how to map your website structure to your controller architecture I would recommend the following.

• don't try to map your navigation but rather the application logics
• one controller for each logical unit of functions
• inside the controllers, one public method for each view
• rather lean controllers which mainly play gateway between models and views

So for example if in your case gameoverview is just a list, it doesn't need its own controller but rather is just a method in the indexcontroller that gets the list from the model and sends it to the respective view. But if your gameoverview is a complex mechanism with many possibilities and different subviews, etc. you could have an overviewController with several methods for the different views and tasks.

I really recommend looking into Zend Framework and how these problems are solved there. IMO you can learn really a lot about the topic of your question by doing that.

CodeIgniter is a great tool for MVC beginners, I would suggest you look at net.tutsplus.com there is an ongoing video tutorial on CodeIgniter

added

for beginners wanting to dive into CI, links to videotuts:

• CI day 1
• CI day 2
• CI day 3 - sending emails
• CI day 4 - newsletter signup
• CI day 5 - basic CRUD
• CI day 6 - login
• CI day 7 - pagination

added

I don't recommend CI as great and powerful framework, but it's simple for beginners and they can learn a lot from it, personally i'm in favor of Symfony and Yii

Wikipedia is probably better at explaining this, but basically,

your model represents, and abstracts, your underlying data (e.g. provides an abstraction layer so the other elements don't have to interact with the database... or even know that it is there).

your controller handles requests to change the model.

your view is the display of part of the model and feedback from the controller.

Neither the controller nor the model should handle display. display. Neither the model nor the view should handle incoming POST data or the like. Neither the controller nor the view should deal with the data sources.

see http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller#Description for a good description of the roles.

What you describe in the question does not fit this description. There should be, say, one controller per model class (or less) to handle requests to the elements those model classes represent.

Your views should not be explicitly tied to any one controller or model element. the view represents a subset of the model as a whole.

The only interaction between a view and a controller is the display of feedback.

Hopefully that helps.

EDIT: As other have pointed out there are a number of MVC frameworks already built. (See http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller#PHP for a list) and I'd advise against being too attached to a framework you've already built if there's another that does the job better.