Cita:
Iniciado por rogertm 
Bueno, según entiendo, el modelo es donde tengo mis datos, ya sea en consultas a la BD o lo que sea... Entonces en este modelo almaceno en un array las posibles respuestas para cada formulario (como si las almacenara en una BD, ¿no?)
Muchos limitan el modelo a eso, pero no es así.
Un modelo es una entidad para tu aplicación, un concepto, un objeto que deberás tratar. Dices estás desarrollando un sistema de gestión de documentos, entonces un "documento" será un model, un "usuario" que creará ese documento será otro modelo, un "almacen" quizá podría ser otro modelo; entidades para tu aplicación. Un "mensaje" no es un modelo, para la solución de un problema en tu aplicación no es significativo, no es una entidad.
La parte de la persistencia --el acceso a una base de datos-- es independiente. Aunque lo común es que la información vaya a una BD no debes pensar que es así; la utilización de tu modelo debe ser transparente del medio de almacenamiento, que igual puede ser archivos planos, XML, JSON, etc. La persistencia es asunto aparte, no por ir a parar la información a una BD tiene que ser un modelo.
Cita:
Iniciado por rogertm tengo un formulario de inserción de usuario (registros) en la BD, cuando ese formulario es enviado con éxito, muestro un mensaje que dice: El usuario ha sido insertado correctamente. pero puedo tener otro formulario que es para ingresar documentos y en este mostraría uno que diga: El documento ha sido guardado correctamente.
Primero, del trato de formulario dependen de el framework que utilices, pero sí pueden ser considerados "algo especial". Básicamente son parte de la vista, son elementos HTML al fin y al cabo que deben ser presentados en pantalla, pero por otro lado igual podría tener información relacionada con el modelo por crear campos dependientes de sus atributos y que pueden contener responsabilidades como la validación de información.
Sin embargo, el formulario como tal NO ES el encargado de guardar la información y, en todo caso el formulario podría estar
relacionado con el modelo. Lo que tu planteaste inicialmente es crear un modelo para manejar los mensajes; es a eso lo que digo no creo sea buena práctica.
Cita:
Iniciado por rogertm En cuanto a crear un método en el controlador, lo pensé, pero me di cuenta que voy a necesitar de estos mensajes en varios formularios o lo que es igual, en varios controladores, es por eso que decidí usar un modelo y acceder a él cada vez que lo necesite, no sé si me captas la idea ahora
La idea la entiendo y no duplicar código es bueno y es una objetivo de la orientación a objetos. Yo solo te digo que no por ello debes crear un modelo; habrá otras maneras de evitar la duplicación de código. Por lo que te leo me suena a que es información más relacionada al formulario que al modelo, y así sin más te diría que puedes crear constantes dentro de tu formulario. Si conociera CI quizá podría decirte más ... y sí, leer leer y leer es lo que hace falta
.. a ambos
.
