He visto código escrito donde casi todos los códigos no relacionados con la ruta se pasan a un modelo. También he visto código donde toda la persistencia de la base de datos es manejada por un modelo, pero el controlador controla el procesamiento que no es de DB.en MVC, ¿dónde dibuja la línea entre un controlador y modelo?
¿Cuál es el mejor enfoque?
La línea entre el controlador y el modelo es bastante clara.
El modelo es el corazón de su aplicación. Contiene la lógica de negocios/dominio requerida para resolver el problema para el que se escribió su aplicación. El Modelo generalmente está en capas en varias otras capas, p. persistencia, servicios, dominio, etc. Es un concepto erróneo común que el Modelo es solo la base de datos, tanto como una idea errónea común de que la base de datos debe ser un ActiveRecord.
El controlador (y la vista) son parte de la capa de presentación. La única responsabilidad de un controlador es recibir y manejar las entradas del usuario dirigidas a su aplicación y delegar esto a las partes apropiadas en el modelo. Nada mas. No debería manejar el flujo de aplicaciones complejas o el código de su dominio problemático. You want controllers to be skinny and models fat with logic. El modelo no debe saber acerca de C o V y usted debería ser capaz de intercambiar V y C para una capa de presentación diferente sin tener que tocar el M.
Ver MVC Excerpt in Patterns of Enterprise Application Architecture
Me paro (o más bien, me siento en mi silla en el escritorio de mi computadora ...) corregido. +1 – BoltClock
posible DUP? http://stackoverflow.com/questions/467113/fat-models-skinny-controllers-and-the-mvc-design-pattern –