MVC—Just Another Acronym?

MVC is a means of organizing a dynamic website. The design pattern has been around since 1979 when it was first described by the Norwegian, Trygve Reenskaug. Here's an outline of the different types of files:

• Models are objects, which represent the underlying data. They hover above the database and access it as required. They can also perform operations on data to add meaning to it.

• Views show the state of the model. They are responsible for displaying information to the end user. (Although they are normally HMTL views, they might be any form of interface. They might be views specially adapted for small PDA screens or WAP telephones, for example.)

• Controllers offer options to change the state of the model. They are responsible for consulting models. They provide the dynamic data to views.

CI has subfolders for models, views, and controllers. Each file within them is a .php file, usually in the form of a class that follows certain naming conventions.

CI helps you to follow the MVC pattern, and as a result makes it much easier to lay your code out. CI allows you a lot of flexibility, and you get all the advantages of the MVC structure.

Try to think in MVC terms as you write. As far as possible, try to keep your 'views' focused purely on presentation, and your 'controllers' purely on controlling application flow. Keep the application logic in the data models and the database.

This way, if you do decide to create a new set of views for a new display method, you don't have to alter much code in any of the controllers or the models. If you update some of your 'business logic', you only have to change code in the models.

On the other hand, while this is a very interesting and useful division, it's important not to take it too seriously. MVC is intended to help you and not to be a straitjacket. Different programs and frameworks implement MVC in slightly different ways. The CI forums contain many anguished queries about the 'right' way to implement MVC. (Should I do database queries from controllers, or should this only be done in models? Can I return a view directly from a model, or should I go through a controller first?)

Rather than trying to achieve the theoretically 'right' result, just keep in mind the two useful principles. These are set out in the Design and Architectural Goals section of CI's User Guide:

• Loose Coupling: Coupling is the degree to which the components of a system rely on each other. The less the components depend on each other, the more re-usable and flexible the system becomes. Our goal was a very loosely coupled system.

• Component Singularity: Singularity is the degree to which components have a narrowly focused purpose. In CodeIgniter, each class and its functions are highly autonomous in order to allow maximum usefulness.

These were Rick Ellis's objectives in building CI, and they are good objectives for your own sites too. Provided that you meet these objectives, it doesn't matter very much what your code sections are called.

It does work. My own experience is that 'loose coupled' helpers or libraries written for one site can be very easily dropped in to another, saving hours of development time.

So, if your controller queries the database directly, or your model calls a view, the CI code will work properly — there's usually no technical issue—but your MVC interpretation may not be 'correct'. Don't worry, be happy!

Was this article helpful?

0 0

Post a comment