¿Validación de reglas en la capa de datos o dominio?

Question

He estado leyendo Pro ASP.NET MVC Framework, Steven Sanderson, y en el capítulo 11 se analiza la validación de datos.

En la página 390 vemos la sección Moviendo la lógica de validación a la capa de modelo. En esta sección, vemos, en la página 392, algunos códigos que muestran cómo implementar la validación.

El código implementa un método GetRuleViolations() y el método Save() lo usa para lanzar un RuleException si algo no estaba bien.

Me parece, sin embargo, que hay hay distinción entre la capa de dominio y una capa de acceso a datos, aquí está el código:

public void Save() { 
    var errors = GetRuleViolations(); 
    if (errors.Count > 0) 
     throw new RuleException(errors); 

    // Todo: Now actually save to the database or whatever 
} 
private NameValueCollection GetRuleViolations() { 
    // validations... 
} 

En un proyecto que estoy trabajando, tengo un Capa de dominio, tan persistente-ignorante como sea posible, y una Capa de acceso a datos, implementando el acceso a datos a través de NHibernate, e implementando los repositorios cuyas interfaces se definieron en la capa de dominio.

Si implemento las reglas de validación como el autor propone aquí, en el método "Save()", irían a mi capa de acceso a datos, aunque, al menos creo que deberían residir en el modelo de dominio.

lo tanto, mi pregunta es: al crear un aplicación en capas, con una capa dominio la implementación de las entidades del dominio y la exposición de las interfaces a los repositorios (persistencia ignorantes), una capa de acceso a datos la aplicación de los repositorios de la capa de dominio e implementando todo el código de acceso a datos, donde deberían residir las reglas de validación?

Mi interfaz principal (o al menos primera) será una aplicación ASP.NET MVC, si eso pudiera cambiar algo.

Gracias.

Answer 1

En una arquitectura MVC, la M (modelo) incluye tanto la capa dominio capa y acceso a datos. Entonces, no hay nada de malo en el ejemplo de Sanderson. Dicho esto, cuando implemente su modelo de dominio utilizando ambas capas (en lugar de tener solo una), la lógica de validación por ejemplo, en cada repositorio concreto).

Answer 2

duda ellos pertenecen a la capa de dominio (donde se podía aplicar IDataErrorInfo, pero eso sólo sería útil para las formas de Windows o aplicaciones WPF creo).

Parece que esta filosofía de validación es muy similar a la expuesta por Paul Stovell (consulte this article of his). Es muy poderoso y lo uso mucho. Básicamente:

1. No hay nada malo en tener un objeto de negocio válido, siempre y cuando no se trate de persistir la misma.
2. Cualquiera y todas las reglas rotas deben poder recuperarse del objeto comercial, de modo que el enlace de datos, así como su propio código, puedan ver si hay errores y manejarlos adecuadamente.

Así, tan ignorante como su capa de dominio es de asuntos de persistencia, creo que sus entidades deben ser al menos consciente de cuando están siendo persistieron. El método Save es una manera de hacerlos responsables de su propia persistencia (que posteriormente pueden delegar en una capa de acceso a datos ). No puedo ver nada malo con esto.

Answer 3

Normalmente prefiero siempre válido objetos de dominio. Los objetos de dominio solo se pueden cambiar mediante métodos que impiden que el objeto se vuelva inválido.

Por otro lado, los objetos de presentación pueden contener valores inválidos temporales o valores que no se pueden analizar correctamente. Pero las llamadas a métodos solo se emitirán a los objetos de dominio por la capa de presentación cuando los datos sean válidos.

Los objetos de dominio imponen invariantes, los objetos de presentación indican al usuario cómo debe modificar su entrada para respetar las restricciones.

Answer 4

La validación debe hacerse en la capa de su dominio. Su lógica comercial es parte del dominio, no del acceso a los datos. La validación no puede hacerse dentro del propio objeto de dominio (la clase real), sino que debe vivir dentro de la capa de dominio.