MVC design in codeigniter PHP

When should a new model or controller be made? Should the开发者_如何学Cre only be controllers that go with a corresponding view 1 to 1 and like so with controllers and models? Or is it good practice to have controllers for functionality not tied up with any particular view? Take for example voting, should all voting code go in a voting controller or be spread among controllers that have views using voting. Seems likely a voting controller would be best.

---

First of all , you cannot actually implement classical MVC in php. The best you can do is Model2 MVC.

• Model - responsible for all the business logic. Has no clue about where the data is stored or actually comes from. The storage and retrieval is responsibility of DataMappers or DAOs. Model itself should never contain SQL. Ever.
• Controller - binds model(s) to the view and changes the state of both. It does not retrieve information from models for sending it to view.
• View - responsible for all presentational logic. Retrieves information from models and binds it to appropriate templates. View itself is not a template.

You can wither have 1:1 relationship between views an controller or many:many. it depends on how you implement the view itself.

For example, your view can require a separate object which handles the rendering. And providing different type of objects ( this is where polymorphism matters ), you can make your view to render either xml, html or json.

Or you can do the same by changing the templates. A ListView class can render a list of articles as well as list of users, if the basic presentation logic does not change and you provide just a different template for each.

In the case of voting , it seems ok to have a single controller for all voting related operations, and you can have a single view with switching the templates for your output.

---

Some of this sort of thing is down to preferences and opinion; there's no single correct way. Some approaches might be more flexible, but maybe at the expense of being more complex.

With regard to your example of "voting", that may depend upon how voting is going to be used in your site. Will votes appear on different types of pages? If so, some sort of component is a good approach; the voting component view can then be used to display its data within different pages, with a Voting component controller accepting the results of votes and then maybe redirecting somewhere else (or accepting votes by an Ajax request).

Very often you'll find that a models (and controllers) map more or less 1:1 to tables in a database. So if I have a table users, I might have a corresponding User model, and UserController controller.

Remember what a controller is intended to do: respond to a request, working out which models need to be loaded, then asking them to store, manipulate and return data which is then transferred to the view for displaying. It's fine to have controllers that don't map directly to models. You might have a controller called DebugController that responds to requests to http://examples.com/debug/, and doesn't map directly to a Debug model and table, but gathers information about the system and various models (of course, there is the argument that all that stuff should be wrapped up into a Debug model, which in turn loads other models and assembles the data that the controller requests).

As for views, you will normally have more than one view for a given controller; often one view per action. So UserController::indexAction() has views/user/index.php, UserController::editAction() has views/user/edit.php etc.

---

The approach might be flexible, that is true.

Models - Describe the tier that is communicating directly with database, all the SQL queries. You can have model for each table in DB that will handle all actions connected to that table (select, insert, update, delete). You can have model for each "logical entity", modul in your application that will handle the actions for this entity. Like in your example "Voting", where you can define the logic of this modul. (Check if the user has allready voted, getVoteCount...)

Controler - Handle the request by executing functions in the model (they should not comunicate directly in DB) and passing the processed data to appropriate View. If you need to present the same data differently on different page, the controler should decide on which view to send the data.

View - You need view for each page, form, module in you application. It is on personal experiance how you are going to organize the views.