Validación del lado cliente (validación en las capas de presentación)

Sugerencia

Este contenido es un extracto del libro electrónico, ".NET Microservices Architecture for Containerized .NET Applications" (Arquitectura de microservicios de .NET para aplicaciones de .NET contenedorizadas), disponible en Documentación de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.

Descargar PDF

Incluso cuando el origen de la verdad es el modelo de dominio y, en última instancia, debe tener validación en el nivel de modelo de dominio, la validación todavía se puede controlar tanto en el nivel de modelo de dominio (lado servidor) como en la interfaz de usuario (lado cliente).

La validación del lado cliente es una gran comodidad para los usuarios. Ahorra tiempo que, de lo contrario, dedicarían a esperar un recorrido de ida y vuelta al servidor que podría devolver errores de validación. En términos empresariales, incluso unas pocas fracciones de segundos multiplicados cientos de veces cada día se suma a una gran cantidad de tiempo, gastos y frustración. La validación directa e inmediata permite a los usuarios trabajar de forma más eficaz y producir una mejor entrada y salida de calidad.

Al igual que el modelo de vista y el modelo de dominio son diferentes, la validación del modelo de vista y la validación del modelo de dominio pueden ser similares, pero sirven para un propósito diferente. Si le preocupa DRY (el principio No repetirse), tenga en cuenta que, en este caso, la reutilización del código también puede implicar acoplamiento y, en las aplicaciones empresariales, es más importante evitar acoplar el servidor al cliente que seguir el principio DRY.

Incluso al usar la validación del lado cliente, siempre debe validar los comandos o los DTO de entrada en el código de servidor, ya que las API de servidor son un vector de ataque posible. Normalmente, hacer ambas es la mejor opción porque si tiene una aplicación cliente, desde una perspectiva de la experiencia de usuario, es mejor ser proactivo y no permitir que el usuario escriba información no válida.

Por lo tanto, en el código del lado cliente, normalmente se validan los ViewModels. También puede validar los DTO o comandos de salida del cliente antes de enviarlos a los servicios.

La implementación de la validación del lado cliente depende del tipo de aplicación cliente que está desarrollando. Será diferente si va a validar los datos en una aplicación web MVC con la mayoría del código de .NET frente a una aplicación web SPA con el código de validación en JavaScript o TypeScript.

Recursos adicionales

Validación en aplicaciones de ASP.NET Core

• Adición de validación
  https://learn.microsoft.com/aspnet/core/tutorials/first-mvc-app/validation

Validación en aplicaciones web SPA (Angular 2, TypeScript, JavaScript, Blazor WebAssembly)

• Validación de formularios
  https://angular.io/guide/form-validation

• Validación. Documentación de Breeze.
  https://breeze.github.io/doc-js/validation.html

• Formularios y componentes de entrada de ASP.NET Core Blazor \ </aspnet/core/blazor/forms-and-input-components>

En resumen, estos son los conceptos más importantes en lo que respecta a la validación:

• Las entidades y agregados deben aplicar su propia coherencia y ser "siempre válidas". Las raíces agregadas son responsables de la coherencia de varias entidades dentro del mismo agregado.

• Si cree que una entidad necesita entrar en un estado no válido, considere usar un modelo de objeto diferente, por ejemplo, un DTO temporal hasta que cree la entidad de dominio final.

• Si necesita crear varios objetos relacionados, como un agregado, y solo son válidos una vez creados todos ellos, considere la posibilidad de usar el patrón Factory.

• En la mayoría de los casos, tener una validación redundante en el lado cliente es bueno, ya que la aplicación puede ser proactiva.

Siguiente anterior