L'utilisation du motif Spécification

Question

Comme tout modèle de conception Spécification Motif est un grand concept, mais sensible à l'utilisation excessive par un architecte / développeur désireux.

Je suis sur le point de commencer le développement d'une nouvelle application (.NET et C #) et vraiment comme le concept du modèle de spécification et je suis désireux de faire pleinement usage de celui-ci. Cependant, avant d'aller dans tous les coups de feu, je serais vraiment intéressé à savoir si quelqu'un pouvait partager les points de douleur qui ont connu lors de l'utilisation motif de spécification dans le développement d'une application.

Idéalement je cherche à voir si d'autres ont eu des problèmes dans

• les tests unitaires d'écriture contre le modèle de spécification
• Décider quelle couche les spécifications doivent vivre dans (référentiel, service, domaine, etc.)
• Utilisation partout où le simple fait de if aurait fait le travail
• etc?

Merci d'avance

Answer 1

Comme David l'a souligné dans son commentaire, beaucoup de ce qui est utile sur les spécifications peuvent maintenant être plus succinctement réalisé avec les goûts de LINQ.

Au lieu d'un nouveau type de spécification, vous pouvez créer des spécifications arbitraires à la volée: GetCustomers().Where(customer => customer.IsActive && customer.City == "Oakland");

Ce n'est pas un remplacement complet pour la spécification, cependant, pour deux raisons:

1. Le tri / filtrage passe dans la classe consommatrice après son retour à tous les clients. Si vous faites affaire avec autre chose que en mémoire des objets, c'est sous-optimale (LINQ to SQL et similaires sont des exceptions parce qu'ils compilent et d'optimiser les requêtes et les exécuter sur le serveur / côté distant, en ne renvoyant que les résultats souhaités ).
2. Votre API est grande ouverte à toute requête si vous exposez collections et laissez la spécification aux requêtes LINQ. Si vous voulez limiter ce ou combien peut être récupéré, vous aurez besoin d'un ensemble de spécifications avec lesquelles interroger.

Il n'y a certainement pas besoin de l'utiliser partout, et il est très possible que vous en aurez pas besoin du tout; Je ne connais pas votre domaine ou ce que vous travaillez.

Je pense que le meilleur conseil est de ne pas Rechercher pour l'utiliser. Vous verrez quand cela est justifié, le plus probable lorsque vous commencez à écrire une classe qui ressemble le premier exemple dans l'article auquel vous avez accédé.

Il suffit de le garder dans votre référentiel de schéma mental que vous avez si vous en avez besoin; si vous ne l'utilisez pas, cela signifie seulement que vous ne l'avez pas besoin, et qui est très bien.

Le choix de la couche est soumise à la nature du cahier des charges et de l'utilisation. Dans de nombreux cas, ils sont des aides à l'appui d'une couche de service, mais dans certains cas, ils encapsulent la logique de domaine.

En ce qui concerne les tests unitaires, rappelez-vous que vos spécifications sont des unités ou contiennent des unités. Ne pas tester une méthode qui accepte un cahier des charges avec toutes les combinaisons possibles de spécification; tester eux-mêmes spécifications pour vous assurer qu'ils se comportent comme prévu, et vous pouvez réutiliser les mêmes spécifications avec confiance dans de nombreuses classes et méthodes.

L'espoir qui est un peu utile.

Answer 2

Je ne crois pas LINQ est un remplacement pour le modèle de spécification. Rappelez-vous que la spécification est mieux utilisé pour encapsuler la logique métier. Donc, si l'un de mes besoins d'affaires m'a obtenir tous les précieux clients pour plusieurs fonctions ma déclaration Linq peut ressembler à ceci:

var valuedCustomers = Customers.Where(c => c.Orders.Count > 15 && c.Active).ToList();

Je peux taper cette déclaration sur mon application, mais si je veux ajouter à cette règle que le client doit avoir rejoint avant une date? Eh bien, maintenant je dois aller sur ma demande et changer le Linq. Ou si je change de graphe d'objet (bien que cela ne devrait pas être la seule raison d'utiliser le modèle). Au contraire, quand je pouvais faire quelque chose comme ça

var valuedCustomers = Customers.Where(new ValuedCustomerRule.IsSatisfied()).ToList();

Je suis d'accord que le modèle est plus utilisé, mais il est très utile pour les règles d'affaires qui apparaissent tout au long de votre système afin que vous ne soyez pas mordu quand ces règles changent. Pour moi, il est similaire à partir des requêtes SQL sur tout votre code d'application.

Answer 3

Réponse Mise à jour: Je suis d'accord avec Wix, LINQ est pas de remplacement pour le modèle Spécification. Je n'ai pas assez réputation pour ajouter un commentaire à répondre Wix, je suis juste répondre comme réponse.

par cette spécifications du papier sont principalement utilisées pour faire correspondre un objet de domaine contre une déclaration. Bien que les spécifications renvoient vrai / faux lors de l'appariement contre un objet de domaine, mais qui ne sont spécifications moyennes proposé pour encapsuler une condition booléenne dans votre code.

Je vais continuer plus loin de la réponse de Wix. Si vous avez une défini une spécification ValuedCustomer alors vous avez différentes posibility d'utiliser la règle:

   var valuedCustomer = new ValuedCustomerSpecification();
   //1. You can use this statement to check if a customer is valued or not in your domain
   Customer customer = ....
   if(valuedCustomer.IsSatisfiedBy(customer))

   //2. You can use it to get just valued customers from repository, 
   var valuedCustomers = repository.Get(valuedCustomer);

   //3. You can combine it with other specifications to create composite specifications. Following syntax can vary with implementation
   var seniorValuedCustomer = valuedCustomer.And(seniorCustomer)

Si je comprends bien papier est que l'utilisateur peut interagir avec les spécifications pour atteindre leurs objectifs à condition qu'il y est un besoin et votre application interface utilisateur permet.

Au-dessus du papier mentionné mentionner également quand ne pas utiliser les modèles de spécification.