Wikipedia stipule que le modèle de spécification est où la logique commerciale peut être recombinée en chaînant la logique commerciale ensemble en utilisant la logique booléenne. En ce qui concerne la sélection d'objets filtrant des listes ou des collections, il me semble que Dynamic Linq me permet d'accomplir la même chose. Est-ce que je manque quelque chose? Y a-t-il d'autres avantages au modèle de spécification qui devrait être considéré comme aussi?
EDIT:
J'ai trouvé des messages qui discutent de la combinaison de Linq et du modèle de spécification:
Implémentation du modèle de spécification via Linq par Nicloas Blumhardt (Autofac Dude)
Quelqu'un a-t-il déjà fait cette route et est-il devenu compliqué de maintenir?
4 Réponses :
Je suis un développeur C # et je voudrais utiliser le modèle de spécification, car il est plus proche de mon domaine d'activité. De plus, vous n'avez aucune surprise avec ce modèle, si une classe de spécifications existe, cela devrait fonctionner. Avec Linq, votre fournisseur sous-jacent n'a peut-être pas mis en œuvre certaines fonctionnalités et vous ne le saurez pas avant l'exécution.
Mais définitivement, le plus grand avantage de la spécification sur Linq doit être plus proche de l'entreprise, c'est une mini-DSL. Linq pour moi est une DSL pour la requête de collecte, pas pour le domaine commercial.
Je ne sais pas vraiment Linq, mais il me semble qu'un système de requête déclarative en général est lié au modèle de spécification. En particulier, la mise en œuvre d'un système de requête déclarative en composant des objets ensemble dans un environnement orienté objet. IIRC c'est semblable à ce que Linq fait, fournissant une couche de sucre syntaxique.
Si Linq obsolète complètement le motif, je ne peux pas dire. Peut-être qu'il y a des cas d'angle qui ne peuvent tout simplement pas être exprimés à Linq?
Dynamic Linq utilise des expressions de chaîne pour permettre la construction dynamique de la requête. Nous perdons donc en fait la sécurité de type. Alors que l'utilisation de motifs d'emballage tels que le motif de décorateur de celui-ci est étroitement lié à l'incarnation, le modèle de spécification nous permet de maintenir la sécurité de type dans le code. J'explore à l'aide du modèle de décorateur comme wrapper de requête afin de réutiliser et de construire de manière dynamique des requêtes. Vous pouvez trouver l'article sur le projet de code à: wrappers de requête LINQ
ou vous pouvez vérifier mon blog .
Spécification: J'aime utiliser la spécification lorsque je pense que la règle est suffisamment importante pour être explicite dans le code et elle n'appartient pas naturellement à l'entité . Exemple: est-il à partir du client la responsabilité probablement pas. Donc, avec la spécification, vous pouvez supprimer cette logique du client Donc, je ne pense pas que LINQ remplace la spécification. En fait, cela améliore le motif. Certaines implications de la spécification utilisent Linq en interne avec
< / code> (il n'y appartenait jamais). Vous pouvez créer quelque chose comme isableetoreceivecreditspecification et mettre toute la logique là-bas. Nous pouvons aller plus loin et combiner les spécifications, par exemple: vous pouvez créer un SecureAgespecification et un ASSETGeaterThanspecification et utilisez-les pour composer le ISableToreceIVecreDitsPecification . IQuérable
Je suis à peu près confronté à cette situation exacte, donc cette question m'intéresse beaucoup.