Validation des règles sur la couche de données ou de domaine?

Question

Je lisais Pro ASP.NET MVC Framework, Steven Sanderson, et au chapitre 11, il traite de la validation des données.

À la page 390, nous voyons la section Déplacement de validation de logique dans votre modèle couche. Dans cette section, nous voyons, à la page 392, du code montrant comment implémenter la validation.

Le code implémente une méthode GetRuleViolations() et la méthode Save() l'utilise pour lancer un RuleException si quelque chose n'allait pas.

Il semble à moi, cependant, qu'il n'y a pas de distinction entre la couche de domaine et un accès aux données couche, voici le code:

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... 
} 

Dans un projet, je travaille, j'ai Couche de domaine, aussi ignorante que possible pour la persistance, et couche d'accès aux données, implémentant l'accès aux données via NHibernate et implémentant les référentiels dont les interfaces ont été définies dans la couche Domaine. Si j'implémente les règles de validation que l'auteur propose ici, sur la méthode "Save()", elles iraient sur ma couche d'accès aux données, même si, du moins je pense, elles devraient résider sur le modèle de domaine!

Alors, ma question est: lors de la création d'une l'application en couches, avec une couche de domaine mise en œuvre des entités de domaine et d'exposer les interfaces aux référentiels (persistance ignorants), une données couche d'accès aux mise en œuvre des référentiels de la couche de domaine et l'implémentation de tout le code d'accès aux données, où les règles de validation doivent-elles se trouver?

Mon interface primaire (ou au moins première) sera une application ASP.NET MVC, si cela peut changer quelque chose.

Merci.

Answer 1

Dans une architecture MVC, le M (modèle) comprend deux la couche de domaine et couche d'accès aux données. Donc, il n'y a rien de mal avec l'exemple de Sanderson. Cela dit, lorsque vous implémentez votre modèle de domaine en utilisant ces deux couches (au lieu d'en avoir une seule), la logique de validation doit aller à la couche domaine pour augmenter la cohésion des objets du domaine et éviter la duplication de la logique de validation par exemple dans chaque référentiel concret).

Answer 2

Ils appartiennent certainement à votre couche de domaine (où l'on pouvait mettre en œuvre IDataErrorInfo, mais ce serait utile que pour Windows Forms ou des applications WPF, je pense). Il semble que cette philosophie de validation soit très similaire à celle exposée par Paul Stovell (consultez this article of his). C'est très puissant et je l'utilise beaucoup. En gros:

1. Il n'y a rien de mal à avoir un objet métier non valide, tant que vous ne cherchez pas à persister il.
2. Toutes les règles rompues doivent être récupérées à partir de l'objet métier, afin que la liaison de données, ainsi que votre propre code, puissent voir s'il existe des erreurs et les gérer de manière appropriée.

Ainsi, aussi ignorant que votre couche de domaine est des questions de persistance, je crois que vos entités devraient être au moins au courant quand ils sont persistaient. La méthode Save est un moyen de les rendre responsables de leur propre persistance (qu'ils peuvent ensuite déléguer à un Data Access Layer). Je ne vois rien de mal à ça.

Answer 3

Je préfère généralement toujours valide objets de domaine. Les objets de domaine ne peuvent être modifiés que par des méthodes qui empêchent l'objet de devenir invalide. D'autre part, les objets de présentation peuvent contenir des valeurs temporaires non valides ou des valeurs qui ne peuvent pas être analysées correctement. Mais les appels de méthodes ne seront envoyés aux objets de domaine que par la couche de présentation lorsque les données sont valides.

Les objets de domaine imposent des invariants, les objets de présentation indiquent à l'utilisateur comment il doit modifier son entrée pour respecter les contraintes.

Answer 4

La validation doit être effectuée dans votre couche de domaine. Votre logique métier fait partie du domaine, pas de l'accès aux données. La validation ne peut pas être effectuée à l'intérieur de l'objet de domaine lui-même (la classe réelle), mais elle doit être à l'intérieur de la couche de domaine.