Understanding MVC and CakePHP

Continuing with the trend of CakePHP information here, I’m going to cover some of the acronyms and lexicon of CakePHP. I hang out a lot on #cakephp and there are repeating trends in some of the questions that get asked so hopefully I can answer some of those questions here. As well as provide a bit of my personal experiences.

What is MVC ?

MVC is a design pattern with three major players. In MVC There are models, views and controllers. These three pieces provide logical separations for your code. Models encapsulate all Database and data manipulation functionality. They are responsible for creating saving, deleting and retrieving data. Personally I’m a subscriber to the ‘Fat Model’ school of thought. This approach wants to put as much logic into the model as possible. This allows for the most code reuse, as more code is located in the reusable model objects, and not your controllers.

Controllers regulate the interaction between Models and Views. Performing a traffic cop like role. They regulate the user, interacting with the Models and passing what is needed onto the Views. Controllers also allow you to decouple your Model functions and your presentation logic. As both the model and the view know nothing about the implementation of the other. The parts can be re-factored and swapped out with far less impact than in a coupled situation. Controllers also provide a way through routing to bind urls to specific controllers and actions. But routing is for another day.

The View is the presentation layer of MVC. The View is responsible for receiving data from the controller and deciding how to display it. It has no direct access to the Model and shouldn’t, as that would likely couple your model to the view.

Why use an MVC framework?

There are many reasons to use an MVC framework like CakePHP over traditional home-brew. First is a predictable structure, we have all had to go through another developer’s ‘framework’ and been befuddled by the way things were done, SQL mixed in with template code etc. When you use a framework like CakePHP you are forced to follow its basic structure. Controllers, Models and Views all have their places. And while frustrating at first, it is a huge time and energy saver in the long run. Structure and regularity are your friends, embrace them. Another reason to use a framework is that most of the boring and tedious tasks are complete. You don’t have to deal with writing tons of SQL or writing the basic functions for routing requests and escaping data. You can just start dealing with your specific application and its domain logic.

What about all this extra jargon?

All of the previously mentioned power and utility comes at the initial cost of lot of jargon and extra terms to learn. In addition to the terms used by the language the framework is built in. Again CakePHP is no exception, and has a set of terms that mean specific things in the framework. A quick review of some of the more commonly queried CakePHP terms.

Component

A Component is a modular block of code that is used by controllers. It encapsulates a specific set of functions that would be needed in more than one of your controllers. They usually act like micro-controllers, or perform common controller functions. Good examples of this are the built in Session Component, and the Auth Component. Both provide a very useful and powerful set of features, that you need in more than one controller. Respectively session and authorization management. If what you want is reusable controller functionality specific to one type of thing or task, look no further than a component.

Behavior

Behaviors are new and welcome addition in CakePHP 1.2. They are functionally very similar to components in what they accomplish. Behaviors allow you to easily reuse model code. If you’ve ever written and model that deals with uploading files or implementing MPTT you don’t want to have to do it again. Refactoring that code into a behavior allows you to reuse that code many times, in many different models. If you want to create reusable model functions that allow a model to perform a type of task or function use a behavior.

Helper

Helpers are the sister to Components but used in the View. Helpers encapsulate functionality that you will use in many views. An excellent example of this is the Form Helper. Writing forms is boring and painful. The Form Helper makes this a far more enjoyable process by encapsulating all the logic in generating the necessary HTML. So if what you want is reusable code generating/processing functions use a helper.

Element

Elements are page fragments. An Element is best described as a block of HTML that is used in one or many Views. The perfect example of this is a recent posts listing. Writing that out the templating for a recent post list on every page you need is insanity and not very DRY. Using an element allows each view that uses an element to be updated at once, making maintenance and your life easier.

There is much more than this simple overview to an MVC stack like CakePHP and its associated terms, however I think this covers a lot of the basics that pop up time and time again.