cObaia.net

CakePHP is great, I love this framework, it’s really fast to develop and it’s possible to maintain a great code inside this framework, I like the rules that CakePHP impose, I like that CakePHP is an obstructive framework, it makes easy to training the team, and put new members inside the team, and to everyone keep one standard.

BUT, one problem that comes not just with CakePHP but with several frameworks, is the usage of the Model. it’s not really a problem, but I think that is the way that people learned MVC with the framework, and the way that we see the Controller.

Frameworks, such as CakePHP, Rails and so on, impose that Model is database access (not really, but they come with this access).

Is that wrong? NOT really wrong…

As the fact that normally your application will need to save data into one database, or filesystem, etc… So provide one database access inside our model probably will help us.

What is the problem?

The problem comes when you see your model as JUST one database access layer, see the model as the thing that will store our data. So we start write the system logic inside the Controller, and this Controller starts to grow, because it already has several roles in our application, it handle the request, it handle the input, it call the model, it call the view… and it also get an additional role that is have the system logic. So our controller get FAT, hard to maintain, hard to change, hard to test, hard to change. It start to has the action methods, some other private/protected methods to implement logic, and it get ugly, strange, BIG.

What about our model?

The model keep thin, with no methods, no logic, just with the relationships of our database, with the validation… does it seems strange for you?

So what hell we are not using our model?

YES, we should use our model to make the logic of the system, is that the M of our application, is what Model must be, and is what the Model is expecting.

How we can start use our model as the logic part of our applications?

1. STOPING to see the Model as your database access;
2. Writing methods inside our models;
3. Creating models without usage of database;
4. Making the models talks each other;
5. Importing libraries, objects inside or model;
6. Creating one API inside or models, to make easy the calls for the controllers;
7. Make your controllers as  much thin as possible.

What will be your gains?

1. You will probably have more freedom to make your logic;
2. Your code will be more simple to maintain;
3. It’s simple to write test for Models;
4. You will have a better OO structure of your logic;
5. You will start think different about Behaviors, Components in CakePHP;
6. Your controller will be thin, and make just what he should do, nothing else;
7. You will stop rewrite code, the model can be called in any controller that you want;
8. With a good structure of logic, it will be so much easy to upgrade your code to new versions of  the framework, or why not, migrate to another framework, as the fact that your logic system will not depends more of the features that CakePHP has.

To summarize, CakePHP is great, it has great tools to make our development fast, but what we can not do is misunderstand the MVC, and starts to be addict with bad practices.  Frameworks like Zend make it more simple to understand, because it not provides directly in the model one database access, BUT anyway in CakePHP we can make the thing correct too, and get everything good of the framework.

So the idea behind the post is not forget the Controller, but pay much more attention in your Model.