DDD y validación del lado del cliente

Question

He estado buscando en StackOverflow para una publicación similar y sí, hubo algunas discusiones sobre lo que estoy a punto de preguntar, pero decidí comenzar un nuevo tema.

Supongamos que tiene una aplicación que utiliza el patrón de modelo de dominio, DDD y muchos otros patrones de diseño. Suponemos que tenemos una serie de soluciones que se enumeran a continuación:

• Solution.Model
• Solution.Repository
• Solution.Services
• Solution.Presentation
• Solution.UI.Web

La capa de experiencia del usuario será Solution.UI.Web y supondremos que será una aplicación ASP.NET WebForms. ¿cómo se aplica la validación del lado del cliente?

Hay una serie de cosas a considerar:

En primer lugar, no debería tener que golpear el servidor (s) aplicación/base de datos para devolver cualquier error de validación al cliente, sin embargo, podríamos poner en práctica validación del lado del servidor también, pero vamos a necesitar la validación del lado del cliente también.

En segundo lugar, no queremos implementar las reglas de validación en la capa de experiencia del usuario. Eso es porque si su aplicación es una aplicación web y luego decide crear un cliente WinApp, tendrá que implementar las reglas de validación una vez más -> pesadilla de mantenimiento.

Un enfoque simple sería implementar su lógica de validación con sus objetos ViewModel (vistas planas de las entidades de su dominio que se enviarán al cliente) y luego validar esos objetos antes de llegar a la aplicación/servidor de bases de datos.

Otro enfoque, uno que he visto usado muchas veces en diferentes aplicaciones, es simplemente generar una colección de mensajes de error de validación y enviar esa colección al cliente. Está bien, pero hay un problema. solo un simple mensaje de resumen de errores de validación no funcionará, especialmente si tiene un formulario de entrada de datos grande.

Ahora el marco de ASP.NET MVC hace la vida mucho más fácil. puede usar EF + DataAnnotations, y MVC Scaffolding Framework puede hacer la mayor parte del trabajo por usted. pero ese es el caso si quieres crear una aplicación MVC e implementar tu lógica de validación con jquery y script java.

Pero, ¿y si necesita un enfoque más genérico para implementar un marco de validación que pueda utilizarse y utilizarse en diferentes aplicaciones, digamos WinForms y WebForms?

Solo para aclarar, lo que busco es un conjunto de patrones de diseño/principios y/o técnicas/marcos para implementar un marco de validación que se pueda implementar con su modelo de dominio y luego aplicar en sus aplicaciones cliente. Y -> no quiero simplemente devolver una colección de mensajes de error de cadena sobre las reglas rotas o algo así, quiero poder actualizar mis controles de datos vinculados (TextBox, ComboBox, DateTimePicker, etc.) después de la falla de validación para que la capa de experiencia del usuario sería más intuitiva (si se quiere).

He visto algunas implementaciones y marcos aquí y allá, y he usado la validación del lado del cliente ASP.NET MVC desde hace un tiempo. entonces mi respuesta no tiene nada que ver con la validación de MVC o JavaScript.

P.S Si usted podría mencionar enlaces de referencia, libros, artículos, ejemplos de proyectos y/o incluir fragmentos de código que sería genial.

TNX, Armin [:

Answer 1

no he llegado a través de una solución de validación que todo lo abarca. Una razón para esto es que la lógica de validación puede ser sutilmente diferente dependiendo de la capa de aplicación. Por ejemplo, no todas las reglas aplicadas por la capa de dominio pueden imponerse en el lado del cliente, por lo que siempre habrá casos en que pueda pasar la validación del lado del cliente y aún así tenga que mostrar un mensaje de validación que se haya propagado desde la capa de dominio.

Sin embargo, el modelo de validación en ASP.NET MVC es extensible y se puede extender a apoyar las reglas de validación adicionales o evento un marco de validación que no sea DataAnnotations. Here es un ejemplo de integración del bloque de Validación de la Biblioteca Empresarial con ASP.NET MVC, sin embargo, como se señala en el artículo, la validación del lado del cliente no se implementó. Otro enfoque sería usar los atributos de DataAnnotations en su capa de dominio. El espacio de nombres de DataAnnotaciones no está vinculado a ASP.NET MVC.

El desafío en estos enfoques sin embargo es que la propagación de las reglas de validación de objetos de dominio para ver los modelos. En teoría, puede extender AutoMapper de manera que las reglas de validación de un modelo de dominio se transfieran para ver las clases de modelo, sin embargo, el costo de implementación y mantenimiento puede superar los beneficios de esta solución.

El marco Fluent Validation podría ser utilizado como un punto de partida para una solución de validación abarca todo. Hay muchos examples de usar este marco con ASP.NET MVC.

Answer 2

En DDD, el dominio suele ser autovalidante. En otras palabras, los objetos no pueden estar en estado inválido. Los objetos de valor ayudan mucho aquí. Simplemente encapsulan las reglas de formato. Por ejemplo, puede tener la clase ZipCode que está garantizada para estar siempre bien formada. Como una responsabilidad adicional que puede tener un método estático como ZipCode.TryParse o ZipCode.Validate que se llevará a cadena arbitraria como parámetro y validar. De esta manera, la lógica de validación se concentra en un solo lugar. Si sus objetos de dominio son accesibles directamente desde la UI, entonces no necesita duplicar esta lógica en ningún otro lado. Este es el caso para clientes gordos (Windows Forms, WPF). Lamentablemente, no hay forma de evitar una duplicación para los clientes web cuando se requiere que realicen la validación sin tener que realizar un viaje de ida y vuelta al servidor.

Answer 3

Usted debe encapsular la lógica de validación en las clases simples que representan el conocimiento del dominio.

que escribir sobre ello en mi post primitive obsession blog. Así es como el controlador de ASP.NET MVC puede verse como si se crea este tipo de clases:

public class CustomerController : Controller 
{ 
    [HttpPost] 
    public ActionResult CreateCustomer(CustomerInfo customerInfo) 
    { 
     Result<Email> emailResult = Email.Create(customerInfo.Email); 
     Result<CustomerName> nameResult = CustomerName.Create(customerInfo.Name); 

     if (emailResult.Failure) 
      ModelState.AddModelError("Email", emailResult.Error); 
     if (nameResult.Failure) 
      ModelState.AddModelError("Name", nameResult.Error); 

     if (!ModelState.IsValid) 
      return View(customerInfo); 

     Customer customer = new Customer(nameResult.Value, emailResult.Value); 
     // Rest of the method 
    } 
} 

No hay necesidad de utilizar las anotaciones, ya que en esencia lo que animan a duplicar la lógica de validación.

comparar estos ejemplos de código:

• With primitive obsession
• Without primitive obsession