Jani Hartikainen has a new post to his blog today about why, in your framework-based applications, it's okay to have "fat controllers" instead of a service layer.

Here’s a counterpoint to the currently popular view of "fat controllers are bad", and the current fad of everyone and their cousin implementing service layers: You don’t need one. Fat controllers are okay too.

He starts by explaining the "why you don't need a service layer" part, mentioning that keeping it in the controller keeps things simple and keeps your code from having to go through extra hoops just to work correctly. He also points out that, just because he recommends "fat controllers" doesn't mean he's advocating code reuse. In fact, just the opposite:

It’s fine if you code your things in the controllers, but there comes a point when you should stop that. The moment you realize you’re duplicating your code, stop and refactor. This is one of the very basics of software engineering: Avoid duplication by creating functions and classes.

This new article on Developer.com advocates one way of working with the MVC pattern in your framework-based applications - fat models and skinny controllers.

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.

Chris Hartjes continues his series looking at converting over legacy applications into a CakePHP environment with this third part, a focus on what can be one of the hardest parts - separating out business logic and presentation logic.

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.

In a today, Chris Hartjes talks about fat models and skinny controllers:

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.

In a today, Chris Hartjes talks about fat models and skinny controllers:

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.