Uno de los objetivos principales de utilizar un framework MVC como es el CakePHP es justamente apegarse lo más posible al paradigma que se propone para de esta forma poder exprimir a fondo su funcionalidad y lograr que nuestro código quede lo más ordenado y mantenible posible.
De esto surge la pregunta de qué responsabilidad debería tener cada capa y de qué lógica manejar en cada una, una aproximación podría ser la siguiente:
Capa Vista
La capa de vista en mvc (particularmente los archivos .ctp y demás archivos de vista) deberían manejar solo lógica de presentación de datos, es decir, no deberían por qué tener ningun tipo de validación que no tenga que ver con la forma de mostrar los datos, a excepción de las validaciones del lado del cliente que pueden estar generadas con javascript.
Capa Controlador
En esta capa deberíamos encontrar toda lo que llamamos lógica de aplicación. Es decir, aquellos procesos que tienen como finalidad mediar entre las vistas y los modelos pasando y procesando información entre unos y otros.
Capa Modelo
Esta es una de las capas más importantes de nuestro paradigma mvc y por ende hay que prestar especial atención en la misma para asignarle la responsabilidad que debe tener y que la misma no recaiga sobre el controlador, cosa que suele pasar cuando uno no el tiempo para pensar en cuestiones de diseño antes de picar código.
Este modelo debe incluir toda la lógica de negocio, es decir, no solo debe incluir la lógica para persistir los datos en la base de datos y recuperarlos si no que principalmente debe incluir lógica sobre qué se puede, que no se puede y qué se debe hacer.
Por ejemplo, pensemos en un sistema que implementa usuarios. Los usuarios pueden realizar comentarios. Si en un modelo nos piden eliminar un usuario nosotros debemos borrar todos los comentarios que ha realizado ese usuario también. Esto es una decisión de negocio y por este motivo debe ser responsabilidad del modelo. Podriamos haber también decidido (por una decisión de negocio) mantener los registros de los comentarios borrados y de esta forma el modelo no borraría los registros de los comentarios.
Otro clásico en esta capa es la validación de datos antes de que la misma sea persistida. Es decir el modelo antes de persistir la información debe comprobar que la misma responda a las reglas de negocio definidas. Si un posteo debe tener un usuario asociado se debe comprobar que la user_foreing_key del post a persistir no esté vacía, si en cambio definimos como una regla de negocio que un posteo puede ser anónimo, no deberíamos comprobar y validar esto.
