Disons que j'ai un poco comme SO:
public List<Error> Validate()
{
var errors = new List<Error>();
if (String.IsNullOrEmpty(FirstName))
errors.Add(new Error("FirstName", "You must fill out first name."));
if (String.IsNullOrEmpty(LastName))
errors.Add(new Error("LastName", "You must fill out last name."));
}
3 Réponses :
envisagez d'utiliser un cadre de validation orienté sur les aspects tels que XVal .
Au lieu d'avoir à incorporer vos règles de validation directement dans le code, vous pouvez les ajouter sous forme d'attributs de vos propriétés et déchargez la dépendance. Votre classe ressemblerait à ceci: Pour répondre à votre question, l'ajout de règles de validation à votre POCO est un moyen simple de faire des choses qui vont fonctionner, mais cela peut obtenir Pondéreux à entretenir, et vous devrez appliquer l'interface de validation sur tous vos objets, ce qui est propre mal de tête. La solution d'aspect orientée est une assez élégante qui traite de ces problèmes et de nombreux autres.
J'ai déjà regardé Xval, mais j'ai trouvé un manque distinct de documentation et d'exemples. Peut-être que je vais regarder à nouveau maintenant que j'utilise Poco's.
Maintenant que j'y pense, comment manipuleriez-vous les cas où vous avez besoin de validation plus avancée, par exemple validez-vous d'une chaîne de chemin de fichier pointant sur un fichier physique sur le disque dur?
XVal vous permet de créer des attributs de validation personnalisés. Voici un exemple de page: blog.codeville.net/ 2009/02/27 / XVAL-08-BETA-MAINTENNE-MAINTÉE
Merci, cela m'aide beaucoup!
@Daniel T. - Consultez le bloc d'application de validation (VAB) - Vous pouvez écrire des validateurs personnalisés et contrôler ce qui est appliqué lors de la présentation XML déclarative.
Je ne le ferais pas. Mon poco a tendance à avoir une validation différente basée sur leur contexte. "Les objets de ma personne doivent avoir une adresse dans cette application, mais il suffit d'avoir un numéro de téléphone dans cette autre application" ... est le genre de chose que vous voulez garder un œil sur et être flexible pour.
Je suis un avocat du modèle de domaine anémique, car je réutilise généralement le même domaine, mais affecter un comportement et une validation différents basés sur le contexte (qui pourraient même être des zones différentes de la même application).
Lors de la mise en œuvre de nouvelles fonctionnalités, je regarde généralement ma classe et me pose cette question: cela semble-t-il comme la responsabilité de cette classe ou serait-il plus approprié pour une classe avec un ensemble de responsabilités différent? Nous appelons cette vérification de la "envyon de fonctionnalité" et contribue efficacement à séparer ce que la classe est et ne se préoccupe pas.
D'accord avec votre deuxième paragraphe beaucoup. Il s'agit des raisons exactes que les moteurs de règles sont devenus populaires.
Les modèles de domaine anémique sont inutiles. Vous finissez par recoder la même logique commerciale partout. C'est en fait un anticipateur selon Martin Fowler. Et le modèle anémique n'est rien de plus qu'un DTO.
Alors que les commentaires sont anciens, je pensais qu'il serait utile d'ajouter un lien à Qu'est-ce que Andy fait référence à .
Je ne trouve rien de mal à mettre la validation dans le modèle. Il fonctionne bien avec toutes les technologies d'interface utilisateur de Microsoft, qui s'attendent à ce que le modèle puisse être demandé s'il est valide ou non, et vous ne conservez pas de cartographier une DTO à une autre, uniquement pour remédier à la répétition de votre validation dans une vue ou une modification de modèle (ou pire, ne le mettant que là).
Les règles de votre échantillon sont simples, mais vous devrez souvent écrire des règles plus complexes. Vous devriez probablement vérifier le cadre CSLA.NET.