MVC - Fat Models and Skinny Controllers

i've been doing a lot of work with cakephp lately and it has been amazingly satisfying developing in a framework that encourages great coding practices. more on cakephp, specifically, later. right now, i'd like to present some things i've learned about the architecture that cakephp is built on. i'm talking about the model-view-controller (mvc) architecture of course.

i'm hoping most of you reading know already know a thing or two about mvc but if you don't, here is a quick overview from wikipedia.

model-view-controller ( mvc ) is an architectural pattern used in software engineering . successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. in mvc, the model represents the information (the data) of the application and the business rules used to manipulate the data; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

the view is pretty well-defined and self-explanatory, however the precise boundary between the controller and model is a grey area. it's very common to see simple models with a couple of basic query functions and a very large controller, much of which is spent rearranging, formatting, or massaging the data returned by the queries. pádraic brady in this article suggests, and i agree, that models are the most mis-understood and underused component of the three. i have found that fat models stick to the values and mindset that the mvc initially laid out.

models themselves are often misunderstood to be a simple database abstraction layer or active record component. mistakes like these will usually lead to very ugly-looking, sloppy, code in the controller. the controller's purpose in the big picture is to be the middle-man between the view and the model. passing request data from the view to the model, and returning a response. this should not include things like processing data from the model data before it gets sent to the view.

each method in the controller is normally considered to be a single action in your application. this often  encourages developers to put all their code into that action, ignoring usual coding, design, and oop,  standards. instead, try placing those chunks of code into logical methods in your model. doing this, in the long-run, makes much more logical sense because you can call that same method from any related models.

here is a very straightforward image (notice the size of the layers)