But a framework shouldn't be considered a panacea; it remains paramount for you to continue exploring and implementing best practices, which will further enhance the maintainability, reusability, and readability of your code. One such best practice involves adhering to a design decision that produces "fat models" and "skinny controllers." The term "fat" is derived from the idea of packing as much of the data-related logic into the model as possible while maintaining a streamlined, almost barren controller.

The concept applies to several web application frameworks out there, but they use the Zend Framework to talk about the wrong way - putting most of the application logic in the controllers - and what they think is a more flexible, organized way to handle the code. A bit of code is included to help illustrate their point.

Anyway, onto other matters. As you saw in parts 1 and 2, a bug part in having a successful transition from legacy app to CakePHP is having an environment that is well suited to the use of a framework. Having laid out the groundwork for that switchover, it's time to talk about the part of a refactoring or porting that is most difficult: separating your business logic from your display logic.

He talks about fat models, skinny controllers and flexible views with some code to illustrate each. This method makes the models do most of the work while the controllers are more of a go-between for them and the views. The views, then, are pliable enough to work with whatever data might be thrown at them.

He includes an example of this school of thought - an update to a previous project that shows most of the functionality and logic (schedule information being pulled in and parsed) and the controller that, lightly, grabs this information from the controller and, blissfully ignorant, passes it right along to the view to be displayed.