Models, Views, and Controllers

Whenever you create an application, you have to find a way to organize the code to make it simple to locatethe proper files and make it simple to maintain. Like most of the web frameworks, CodeIgniter uses the Model,View, Controller (MVC) pattern to organize the files. This keeps the data, the presentation, and flow through theapplication as separate parts. It should be noted that there are many views on the exact roles of each element,but this document describes our take on it. If you think of it differently, you’re free to modify how you useeach piece as you need.

Models manage the data of the application and help to enforce any special business rules the application might need.

Views are simple files, with little to no logic, that display the information to the user.

Controllers act as glue code, marshaling data back and forth between the view (or the user that’s seeing it) andthe data storage.

At their most basic, controllers and models are simply classes that have a specific job. They are not the only classtypes that you can use, obviously, but they make up the core of how this framework is designed to be used. They evenhave designated directories in the /app directory for their storage, though you’re free to store themwherever you desire, as long as they are properly namespaced. We will discuss that in more detail below.

Let’s take a closer look at each of these three main components.

The Components

Views

Views are the simplest files and are typically HTML with very small amounts of PHP. The PHP should be very simple,usually just displaying a variable’s contents, or looping over some items and displaying their information in a table.

Views get the data to display from the controllers, who pass it to the views as variables that can be displayedwith simple echo calls. You can also display other views within a view, making it pretty simple to display acommon header or footer on every page.

Views are generally stored in /app/Views, but can quickly become unwieldy if not organized in some fashion.CodeIgniter does not enforce any type of organization, but a good rule of thumb would be to create a new directory inthe Views directory for each controller. Then, name views by the method name. This makes them very easy to find lateron. For example, a user’s profile might be displayed in a controller named User, and a method named profile.You might store the view file for this method in /app/Views/User/Profile.php.

That type of organization works great as a base habit to get into. At times you might need to organize it differently.That’s not a problem. As long as CodeIgniter can find the file, it can display it.

Find out more about views

Models

A model’s job is to maintain a single type of data for the application. This might be users, blog posts, transactions, etc.In this case, the model’s job has two parts: enforce business rules on the data as it is pulled from, or put into, thedatabase; and handle the actual saving and retrieval of the data from the database.

For many developers, the confusion comes in when determining what business rules are enforced. It simply means thatany restrictions or requirements on the data is handled by the model. This might include normalizing raw data beforeit’s saved to meet company standards, or formatting a column in a certain way before handing it to the controller.By keeping these business requirements in the model, you won’t repeat code throughout several controllers and accidentallymiss updating an area.

Models are typically stored in /app/Models, though they can use a namespace to be grouped however you need.

Find out more about models

Controllers

Controllers have a couple of different roles to play. The most obvious one is that they receive input from the user andthen determine what to do with it. This often involves passing the data to a model to save it, or requesting data fromthe model that is then passed on to the view to be displayed. This also includes loading up other utility classes,if needed, to handle specialized tasks that is outside of the purview of the model.

The other responsibility of the controller is to handle everything that pertains to HTTP requests - redirects,authentication, web safety, encoding, etc. In short, the controller is where you make sure that people are allowed tobe there, and they get the data they need in a format they can use.

Controllers are typically stored in /app/Controllers, though they can use a namespace to be grouped howeveryou need.

Find out more about controllers