Where should my code go?

by Auzigog
This article helps you understand where you should place new code within the model-view-controller design pattern.
When I started developing my first CakePHP application, I was flustered every time I want to add new code. I didn't know where it "belonged" within the existing framework and conventions. As I found answers to my questions, I started this list.

Before reading this, make sure you understand the model-view-controller design pattern.

The "take away" message for each part is highlighted in bold.

Models

  • Models are designed to hold and manipulate data
  • Models essentially reflect a database table
  • Models (usually) never represent a row in a table, just the table itself
  • Models have functions that deal with manipulating data from the table
  • Models should be large and should contain the majority of the logic for your application--(remember: fat models, skinny controllers)
  • Anytime you are doing the same thing to a model in multiple places, you should refactor that functionality into a method within the model (instead of having it in multiple places outside the model).
  • Cookbook: Understanding Models

Behaviors


Controllers

  • Controllers are designed to separate your site into sections
  • Examples: BlogController, SearchController, GroupsController, UserProfileController
  • Contrary to what the blog tutorial makes you think, there is not a single controller for every model (or a single model for every controller). It is fairly common that a controller will hold all the tasks of a single model, but it is NOT necessary for things to be that way.
  • On the same token, avoid mixing controller uses. While there may not be a controller for every model, don't put actions that deal with model B into model A just to avoid having to create a controller
  • Controllers should be small and NOT contain the majority of the logic for your application--(remember: fat models, skinny controllers)
  • The controller isn't there do do everything. It is there to determine what needs to be done, and have other people do it
  • Controller actions get data ready to be presented in a view
  • Cookbook: Introduction to Controllers

Components

  • Components have logic that is shared across multiple controllers
  • Remember, logic should only be in multiple controllers in the first place if it is getting data ready for the view. If the logic is just manipulating your data, it should be in a model.
  • Cookbook: Introduction to Components

Views

  • Views are individual pages within your site
  • Views are the user interface to your program
  • Each view has a function inside the controller with a matching name. These functions are called actions. Each action gets the data ready for a specific view.
  • Views present data
  • Views allow you to separate your user interface from the rest of your application
  • Cookbook: Introduction to Views

Helpers


Elements

Report

More on General Interest

Advertising

Comments

  • finder posted on 06/23/10 10:50:23 PM
    Hi,

    I am developing an application which has two sets of methods :
    1) Methods which are called from the mobile phone to process payments
    2) Methods which handle the website logic.

    Now, the problem is that both the methods handling the mobile calls and the website logic are present in the same controller. This has made my code very difficult to manage.

    Does anyone have any suggestions on how I can separate my code.

    Thanks a lot
  • djalbani posted on 05/21/09 08:51:18 AM
    Hey

    what do i do if i need to add a picture to my main page and add link to that picture?

    Also tell me how do I add forms to my main page?
  • ryos posted on 05/12/09 04:38:39 PM
    I commonly want to create extra functions in controllers that do not correspond to any action. For example, edit and add actions frequently contain some common logic, and it would be nice to be able to factor that code out and share it. However, in a controller every function is an action, which can be called from the URL; this could have disastrous results.

    I note that declaring a function "private" solves this issue, but is this the way it's "supposed" to be done?
  • tekomp posted on 03/08/09 10:10:24 PM
    How about some examples of different situations and where that code should go? I've come across a number of times when I can't decide if my code should be done in a component, a model, a behavior, or even a datasource. Take the recent Bakery articles for example, there are two Paypal integrations - one component and one datasource. It gets tricky with all the different options.
  • GarthDB posted on 12/30/08 09:19:17 AM
    I heard a bit about it, but what would you recommend for Plugins? What goes there best?
    • rtconner posted on 01/05/09 10:47:15 PM
      I heard a bit about it, but what would you recommend for Plugins? What goes there best?
      Technically you could put any full application as a plugin. So for example you write a full forum, and that could become a plugin that you drop in to projects you want to use it on and just use. Mostly it's meant for open projects with a separate respository (like cakeforge).
  • rafaelbandeira3 posted on 12/29/08 08:32:57 PM
    I couldn't help but get bugged with some items:

    * Models (usually) never represent a row in a table, just the table itself
    - sorry, but, based in what have you came to this conclusion? As far as I know, models - here understood as every subclass of the Model class - have the $id property exactly to deal with that, and there are lots of actions where your model will only represent a single row, actually, one could say that: Models usually represent a row in a table, except when you are paginating, building reports, filling graphs... , or could have just thrown this item away - which is much better in my opinion.

    * Controllers should be small and NOT contain the majority of the logic for your application--(remember: fat models, skinny controllers)
    - I don't think that the concept of "fat models, skinny controllers" applies to this one. "Skinny controllers" only mean you shouldn't handle data inside the controller. or at least as minimum as possible, but the controller still is a "Controller" which means that it "controls" the application state and actions, so, yeah, one can put a lot of logic down there.

    * Components have logic that is shared across multiple controllers
    - Well, not that it's not true, but it's kind of incomplete, Components are far more useful than that, they can be the interface for external sources/servers/actions - access smtp servers, ping, send, post... - and can be wrappers for external libraries.
login to post a comment.