model view controller - ventajas - ¿Dónde pertenece la validación de entrada en una aplicación MVC?

mvc ejemplos

Question

Tengo una aplicación MVC que recibe una entrada de un formulario.
Este es un formulario de inicio de sesión por lo que la única validación que es necesaria es verificar si la entrada no está vacía.
En este momento, antes de pasarlo al modelo, lo valido en el controlador.
¿Es esta una mejor práctica o no? ¿Pertenece al modelo?

Answer 1

Asumiendo que su aplicación está estructurada como:

• Modelo-Vista-Controlador
• Servicio
• Persistencia
• Modelo

La entrada del usuario vendría a su controlador y usted usaría servicios en la capa de servicio para validarla.

Answer 2

Dentro del controlador, tiene la propiedad ModelState a la que puede agregar errores de validación.

Vea este ejemplo en MSDN .

Answer 3

He estado pensando en esto durante MUCHO tiempo y después de tratar de poner la validación tanto en controladores como en modelos ... finalmente llegué a la conclusión de que para muchas de mis aplicaciones ... la validación pertenece al modelo y no al controlador . ¿Por qué? Debido a que el mismo modelo podría ser utilizado en el futuro por varias otras llamadas de controlador o API ... y luego tendría que repetir el proceso de validación una y otra vez. Eso violaría DRY y provocaría muchos errores. Además, filosóficamente es el modelo que interactúa con la base de datos (u otro almacenamiento persistente) y, por lo tanto, es una especie de lugar de "última llamada para el alcohol" para hacer esto de todos modos.

Así que hago mi traducción de obtención / publicación en el controlador y luego envío datos sin procesar al modelo para su validación y procesamiento. Por supuesto, a menudo estoy haciendo aplicaciones web php / mysql y si está haciendo otras cosas, los resultados pueden variar. Espero que esto ayude a alguien.

Answer 4

No creo que haya una mejor práctica oficial que limite la validación a cualquier parte del patrón MVC. Por ejemplo, su vista puede (y debe) hacer una validación inicial usando Javascript. Su controlador también debe ofrecer los mismos tipos de validación, así como más validación relacionada con la lógica de negocios. El modelo también puede ofrecer formas de validación, es decir, establecedores que no permiten valores nulos.

Hay una discusión interesante de esto en joelonsoftware .

Answer 5

Su lógica comercial, entonces no, no pertenece al modelo.

Answer 6

La validación debe estar en el Modelo

Solo el modelo conoce los "detalles" del negocio. solo el modelo sabe qué datos son aceptables y cuáles no. el controlador solo sabe cómo "usar" el modelo.

por ejemplo: supongamos que necesitamos la funcionalidad de registrar nuevos usuarios en nuestro sistema.

El modelo:

 public function registerUser(User $user){
    //pseudo code
       //primitive validation
       if(!isInt($user->age)){
           //log the invalid input error
           return "age"; 
       }
       if(!isString($user->name)){
           //log the invalid input error
           return "name";
       }
       //business logic validation

        //our buisnees only accept grown peoples
        if($user->age < 18){
            //log the error
            return "age";
        }
        //our buisness accepts only users with good physique
        if($user->weight > 100){
            //log the error
            return "weight";
        }
        //ervery thing is ok ? then insert the user
        //data base query (insert into user (,,,) valeues (?,?,?,?))
        return true;
}

Ahora el trabajo del controlador es "usar" la función model registerUser() sin el conocimiento de cómo el modelo va a hacer la validación, o incluso lo que se considera "válido" o no.

el controlador:

$user = new User();
$user->age = isset($_POST[''age'']) ?  $_POST[''age''] : null;
$user->name = isset($_POST[''name'']) ?  $_POST[''name''] : null;
$user->age = isset($_POST[''weight'']) ?  $_POST[''weight''] : null;
$result = $theModel->registerUser($user);// <- the controller uses the model
if($result === true){
//build the view(page/template) with success message and die
}
$msg = "";
//use the return value from the function or you can check the error logs
switch ($result){
    case"age" :
        $msg = "Sorry, you must be over 18";
        break;
    case "name":
        $msg = "name field is not correct";
        break;
    case "weight":
        $msg = "Sorry, you must have a good physique";
        break;
}
//build the view(page/template) with error messages and die

El usuario de la clase

class User { 
    public $age;
    public $name;
    public $weight;
}

tener una arquitectura como esa "liberará" a los controladores completamente de los detalles de la lógica comercial, lo cual es algo bueno.

Supongamos que queremos hacer otra forma de registro de usuario en otro lugar en el sitio web (y tendremos otro controlador asignado para ello). ahora el otro controlador usará el mismo método del modelo registerUser() .

Pero si distribuimos la lógica de validación entre el controlador y el modelo, no se separarán -lo cual es malo y en contra de MVC- lo que significa que cada vez que necesite crear una nueva vista y un controlador para registrar un nuevo usuario, debe usar el mismo controlador antiguo Y el modelo juntos. Además, si se cambia la lógica comercial (ahora aceptamos a los adolescentes en nuestro club deportivo), solo cambiará el código en la función model registerUser() . el código de los controladores sigue siendo el mismo.

Answer 7

Business Logic  -> Controller
Data Validation -> Model