model-view-controller - entre - asp.net mvc framework
¿A dónde pertenece la lógica de procesamiento de formularios en una aplicación web MVC? (4)
En una aplicación basada en la web que utiliza el patrón de diseño Modelo-Vista-Controlador, la lógica relacionada con el procesamiento de los envíos de formularios parece estar en algún lugar entre la capa del Modelo y la capa del Controlador. Esto es especialmente cierto en el caso de una forma compleja (es decir, donde el procesamiento de formularios va mucho más allá de simples operaciones CRUD).
¿Cuál es la mejor manera de conceptualizar esto? ¿Las formas son simplemente un tipo de pegamento entre modelos y controladores? ¿O la lógica de la forma pertenece directamente al campo M o C?
EDITAR: entiendo el flujo básico de información en una aplicación MVC (vea la respuesta de chills42 para un resumen). Mi pregunta es a dónde pertenece la lógica de procesamiento de formularios: en el controlador, en el modelo o en otro lugar.
Yo diría que esto debería verse como 2 acciones separadas ...
- enviando el formulario (V -> C)
- procesar la presentación (C -> M)
Hablando en genéricos, tiendo a pensar como cada acción como un mensaje entre las secciones. La serie completa de mensajes sería algo como esto ...
- Mostrar formulario (C -> V)
- Enviado por el usuario (V -> C)
- Contenido del proceso (C -> M)
- Procesamiento finalizado (M -> C)
- Mostrar resultados (C -> V)
De acuerdo con escalofríos42, pero se sumaría a cosas tanto en el modelo como sea posible.
Cuando un usuario envía (V-> C) se enviará a algún controlador, y yo sostengo que es mejor si el controlador solo actúa como un despachador para decidir qué sucederá a continuación, posiblemente en base a un punto de datos simple. Deje que el modelo tenga un método (generalmente no estrictamente ORM o basado en registros activos), procese los datos brutos y guárdelos en el archivo db, si corresponde, simplemente devuelva un estado o genere un error.
El procesamiento de formularios debe tener lugar en el modelo, porque esa es la capa de la aplicación que recibe y procesa los datos de los controladores a través de las vistas. El controlador lo mueve, pero en cuanto a la ejecución real del código, debería estar sucediendo en sus modelos.
Aunque al principio la idea de usar V -> C, C -> M, M -> C parece buena, cualquier cambio en la forma requiere un error con el controlador + modelo + vista. Eso debe evitarse para mantener la lógica de la aplicación simple. Aquí hay una extensión muy simple del marco que hace que sea realmente fácil manejar el procesamiento de formularios web, delegando la lógica de procesamiento de formularios en una clase separada y manteniendo la arquitectura MVC para manejar la lógica de la aplicación.
Para cada formulario que necesite procesar, cree una clase derivada de una clase genérica "webform" o la clase de modelo codeigniter. Agregue métodos como validate (), process (), display () a esta clase.
En el controlador, el código es así.
class User_controller
{
function login()
{
$form = new LoginForm(); // this is the class you would create
if ($form->validate())
{
$data = $this->user_model->getUserData( $form->userid );
// form processing complete, use the main "user" model to fetch userdata for display,
// or redirect user to another page, update your session, anything you like
} else {
$form->display();
}
}
}
El método de visualización en la clase de formulario carga su propia vista y rellena los datos posteriores a la publicación según lo deseado. Al usar lo anterior, hay algunas ventajas:
No necesita cambiar su controlador principal si la visualización del formulario o las necesidades de procesamiento cambian.
No necesita cambiar su modelo de usuario tampoco
El controlador permanece limpio y maneja la lógica de la página principal
El modelo de usuario permanece limpio y solo interactúa con la base de datos
El marco se puede actualizar para que los formularios web se puedan cargar usando
$ this-> load-> form ("login"); ......
Sin embargo, esa es solo una sugerencia que es útil para el equipo codeigniter.