2008-12-05 15 views
5

En una aplicación basada en web que usa el patrón de diseño Modelo-Vista-Controlador, la lógica relacionada con el procesamiento de envíos de formularios parece estar en algún lugar entre la capa de Modelo y la capa de 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).¿Dónde pertenece la lógica de procesamiento de formularios en una aplicación web MVC?

¿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?

EDIT: Entiendo el flujo de información básico 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.

Respuesta

4

que diría esto, probablemente, debe ser visto como 2 acciones separadas ...

  1. enviar el formulario (V -> C)
  2. trámite de la petición (C -> M)

Hablando en genéricos, tiendo a pensar como cada acción como un mensaje entre las secciones. La serie completa de los mensajes sería algo como esto ...

  • forma de la pantalla (C -> V)
  • enviada por el usuario (V -> C)
  • contenidos procedimiento (C -> M)
  • Procesamiento terminado (M -> C)
  • Mostrar resultados (C -> V)
2

de acuerdo con chills42, pero añadiría a meter tanto hacia abajo 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 simplemente actúa como despachador para decidir qué sucederá a continuación, posiblemente en base a un simple punto de datos. 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.

1

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.

2

Aunque al principio la idea de usar V -> C, C -> M, M -> C parece buena, cualquier cambio en el formulario 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 de la publicación como desee. Mediante el uso de lo anterior, hay pocas ventajas:

  • Usted no necesita cambiar su controlador principal si la pantalla forma o procesamiento necesita cambios.

  • Usted no necesita cambiar su modelo de usuario, ya sea

  • controlador permanece limpio y manejar la lógica principal sigue siendo la página

  • usuario Modelo limpia y sólo interactúa con la base de datos

El marco se puede actualizar para que los formularios web se puedan cargar usando

$ this-> loa d-> form ("inicio de sesión"); ......

Sin embargo, esa es solo una sugerencia que es útil para el equipo de codeigniter.

Cuestiones relacionadas