Gran pregunta!
En términos de desarrollo de la red mundial, ¿qué pasaría si preguntaras lo siguiente también?
"Si se suministra una entrada de usuario incorrecta a un controlador desde una interfaz de usuario, ¿ debería el controlador actualizar la Vista en una especie de bucle cíclico, obligando a los comandos y datos de entrada a ser precisos antes de procesarlos ? ¿Cómo? ¿Cómo se actualiza la vista en condiciones normales? ¿Es una vista estrechamente acoplada a un modelo? ¿La validación de entrada del usuario es la lógica comercial central del modelo, o es preliminar y, por lo tanto, debe ocurrir dentro del controlador (porque los datos de entrada del usuario son parte de la solicitud)?
(En efecto, ¿se puede y se debe retrasar la creación de instancias de un modelo hasta que se obtenga una buena entrada?)
Mi opinión es que los modelos deben manejar una circunstancia pura y prístina (tanto como sea posible), sin la carga de una validación de entrada de solicitud HTTP básica que debe ocurrir antes de la creación de instancias del modelo (y definitivamente antes de que el modelo obtenga datos de entrada). Dado que la gestión de datos de estado (persistentes o de otro tipo) y las relaciones API es el mundo del modelo, permita que la validación de entrada de solicitud HTTP básica ocurra en el controlador.
Resumiendo
1) Valide su ruta (analizada desde la URL), ya que el controlador y el método deben existir antes de que cualquier otra cosa pueda avanzar. Esto definitivamente debería suceder en el reino del controlador frontal (clase de enrutador), antes de llegar al controlador verdadero. Duh :-)
2) Un modelo puede tener muchas fuentes de datos de entrada: una solicitud HTTP, una base de datos, un archivo, una API y, sí, una red. Si va a colocar toda su validación de entrada en el modelo, entonces considera que la validación de entrada de solicitud HTTP forma parte de los requisitos comerciales para el programa. Caso cerrado.
3) ¡Sin embargo, es miope pasar por el gasto de crear instancias de muchos objetos si la entrada de solicitud HTTP no es buena! Puede saber si ** la entrada de solicitud HTTP ** es buena ( que vino con la solicitud ) al validarla antes de instanciar el modelo y todas sus complejidades (sí, quizás incluso más validadores para datos de entrada / salida de API y DB).
Prueba lo siguiente:
a) El método de solicitud HTTP (GET, POST, PUT, PATCH, DELETE ...)
b) Controles mínimos de HTML (¿tiene suficiente?).
c) Controles HTML máximos (¿tienes demasiados?).
d) Controles HTML correctos (¿tiene los correctos?).
e) Codificación de entrada (típicamente, ¿es la codificación UTF-8?).
f) Tamaño máximo de entrada (¿alguna de las entradas está fuera de límites?).
Recuerde, puede obtener cadenas y archivos, por lo que esperar a que se instale el modelo podría ser muy costoso a medida que las solicitudes lleguen a su servidor.
Lo que he descrito aquí afecta a la intención de que la solicitud llegue a través del controlador. Omitir la verificación de intención deja a su aplicación más vulnerable. La intención solo puede ser buena (siguiendo tus reglas fundamentales) o mala (yendo fuera de tus reglas fundamentales).
La intención de una solicitud HTTP es una propuesta de todo o nada. Todo pasa o la solicitud no es válida . No es necesario enviar nada al modelo.
Este nivel básico de intención de solicitud HTTP no tiene nada que ver con los errores de entrada y validación de los usuarios regulares. En mis aplicaciones, una solicitud HTTP debe ser válida en las cinco formas anteriores para que pueda cumplirla. En una forma de hablar de defensa en profundidad , nunca puede obtener la validación de entrada del usuario en el lado del servidor si alguna de estas cinco cosas falla.
Sí, esto significa que incluso la entrada del archivo debe ajustarse a sus intentos de front-end para verificar y decirle al usuario el tamaño máximo de archivo aceptado. ¿Solo HTML? ¿Sin JavaScript? Bien, pero el usuario debe ser informado de las consecuencias de cargar archivos que son demasiado grandes (principalmente, que perderán todos los datos del formulario y serán expulsados del sistema).
4) ¿Esto significa que los datos de entrada de la solicitud HTTP no son parte de la lógica empresarial de la aplicación? No, solo significa que las computadoras son dispositivos finitos y los recursos deben usarse con prudencia. Tiene sentido detener la actividad maliciosa antes, no más tarde. Paga más en recursos de cómputo por esperar para detenerlo más tarde.
5) Si la entrada de la solicitud HTTP es incorrecta, toda la solicitud es incorrecta . Así es como lo veo. La definición de una buena entrada de solicitud HTTP se deriva de los requisitos comerciales del modelo, pero debe haber algún punto de demarcación de recursos. ¿Cuánto tiempo dejarás vivir una mala solicitud antes de matarla y decir: "Oh, oye, no importa. Mala solicitud".
El juicio no es simplemente que el usuario ha cometido un error de entrada razonable, sino que una solicitud HTTP está tan fuera de los límites que debe declararse maliciosa y detenerse de inmediato.
6) Por lo tanto, por mi dinero, la solicitud HTTP (MÉTODO, URL / ruta y datos) es TODO buena, o NADA más puede continuar. Un modelo robusto ya tiene tareas de validación con las que preocuparse, pero un buen pastor de recursos dice "Mi camino o el camino alto. Ven a corregir o no vengas".
Sin embargo, es su programa. "Hay más de una forma de hacerlo". Algunas formas cuestan más en tiempo y dinero que otras. Validar los datos de la solicitud HTTP más adelante (en el modelo) debería costar más durante la vida útil de una aplicación (especialmente si se amplía o reduce).
Si sus validadores son modulares, validar la entrada de solicitud HTTP básica * en el controlador no debería ser un problema. Simplemente use una clase Validator estratégica, donde los validadores a veces también se componen de validadores especializados (correo electrónico, teléfono, token de formulario, captcha, ...).
Algunos ven esto como algo completamente equivocado, pero HTTP estaba en su infancia cuando la Banda de los Cuatro escribió Patrones de diseño: Elementos de software orientado a objetos reutilizables .
================================================== ========================
Ahora, en lo que respecta a la validación de entrada de usuario normal (después de que la solicitud HTTP se haya considerado válida), ¡está actualizando la vista cuando el usuario comete un error en el que debe pensar! Este tipo de validación de entrada del usuario debe ocurrir en el modelo.
No tiene garantía de JavaScript en el front-end. Esto significa que no tiene forma de garantizar la actualización asincrónica de la interfaz de usuario de su aplicación con estados de error. La verdadera mejora progresiva también cubriría el caso de uso sincrónico.
Tener en cuenta el caso de uso síncrono es un arte que se pierde cada vez más porque algunas personas no quieren pasar por el tiempo y las molestias de rastrear el estado de todos sus trucos de interfaz de usuario (mostrar / ocultar controles, deshabilitar / habilitar controles , indicaciones de error, mensajes de error) en el back-end (generalmente mediante el seguimiento del estado en matrices).
Actualización : en el diagrama, digo que View
deberían hacer referencia a Model
. No. Debe pasar los datos View
desde el Model
para preservar el acoplamiento suelto.
![ingrese la descripción de la imagen aquí](https://i.stack.imgur.com/13B4t.png)