Ceci ressemble plus à une bonne question. Je souhaite proposer différentes bibliothèques génériques telles que la journalisation, la mise en cache, etc. Il existe de nombreuses bibliothèques tierces telles que MS Enterprise Bibliothèque, Log4net, NCache, etc..
Je voulais savoir si c'est une bonne pratique pour les utiliser directement ou créer un wrapper sur chaque service et utiliser un DI pour injecter ce service dans le code.
considère
8 Réponses :
Ceci est plus une question subjective, mais imo C'est une bonne chose d'envelopper toute utilisation spécifique d'application / bibliothèque dans une conception de modèle de service qui a bien pensé aux interfaces afin que vous puissiez facilement utiliser di et plus tard si vous devez passer à partir de Dites le bloc d'application de données ENTLIB à NHibernate Vous n'avez pas besoin de ré-architecte que vous êtes une application entière.
Je pense qu'il est préférable d'utiliser une enveloppe, personnellement, simplement parce que ce sont des choses que vous ne voulez pas courir lorsque vos tests d'unité sont exécutés (en supposant que vous testez également des tests unitaires).
Je crée généralement une classe "assistant" ou "service" qui peut être appelée statiquement pour envelopper des fonctionnalités communes de ces bibliothèques.
Je ne sais pas qu'il existe une énorme quantité de risque de référencer directement / les appeler, car ils sont définitivement des projets matures (au moins ENTLIB et LOG4NET), mais avoir un wrapper isole de la confusion de la version de la version, etc. Et vous donne plus d'options à l'avenir, à un coût assez faible.
Si vous souhaitez pouvoir échanger des implémentations de ces concepts, la création d'une enveloppe est la voie à suivre.
Pour la journalisation, il y a déjà quelque chose comme ça disponible commun.logging .
Ceci est subjectif, mais dépend aussi de la bibliothèque.
Par exemple, Log4Net ou NHibernate ont strictement API basé sur l'interface . Il n'y a pas besoin de les envelopper. Il existe d'autres bibliothèques qui permettront de tester vos classes si vous n'avez aucune interface entre les deux. Il peut être souhaitable d'écrire une interface propre.
Il est parfois bon de conseiller de ne laisser qu'une petite partie du code accède à l'API comme par exemple, Nibernate ou une bibliothèque d'interface graphique. (Remarque: Ceci n'est pas emballage, il s'agit de la construction Log4Net est probablement un bon exemple où l'emballage est juste surnombre. Certaines personnes souffrent de "wrappite", qui est anti-motif (parfois appelée "Enroulement laine en coton" ) et produit simplement plus de travail. Log4net a une API aussi simple et est hautement personnalisable, ils l'ont fait mieux que votre wrapper sera probablement.
Vous découvrirez que l'emballage d'une bibliothèque ne vous permettra pas de l'échanger avec un autre produit. La mise à niveau vers les versions plus récentes ne sera pas plus facile, plutôt que vous devez mettre à jour votre wrapper pour rien.
Je conviendrais que Log4Net est une API très simple, mais il n'ya aucun moyen d'extraire toutes les interfaces de Log4net et de le donner aux développeurs afin qu'ils puissent coder utiliser uniquement des interfaces. Sans wrapper, il est très difficile de mettre à niveau la version de la bibliothèque spécifique s'il y a 100 ans d'application à l'aide. N 'y a-t-il pas une autre solution?
tangs: pas 100% pour cent sûr de ce que vous voulez dire. Lorsque vous utilisez LOG4NET, vous utilisez déjà des interfaces. Quand ils décident de le changer, il aura une raison, ils envisageront fortement de la compatibilité et ne le briseront que si cela vaut vraiment la peine. Si vous décidez d'utiliser cette nouvelle fonctionnalité ou cette nouvelle fonctionnalité qui a entraîné la modification de celle-ci, votre wrapper ne le supportera pas de toute façon et l'adaptation de votre enveloppe entraînera les mêmes changements. Il y a changements conceptuels et dépendances que vous ne pouvez pas "coder" en écrivant des emballages.
@stefan: Si vous décidez pas pour prendre en charge de nouvelles fonctionnalités, vous pouvez laisser votre emballage inchangé. Ou s'il y a une interface de rupture, vous changez peut être capable de le gérer dans votre emballage pour éviter de casser les 100 autres applications. Bien sûr, si vous souhaitez utiliser de nouvelles fonctionnalités, votre point est précis à 100% que vous ne pouvez pas les refuser.
@Tuzo: Si vous décidez de ne pas utiliser les nouvelles fonctionnalités, vous ne mettez pas à niveau vers la nouvelle version. S'il est possible de cartographier la nouvelle interface sur l'ancien, elle sera déjà disponible dans le produit, à moins que les personnes qui écrivent sont trop stupides. Donc, la chance que vous obteniez une intégration des changements de rupture gratuite est presque nulle, la chance que vous ayez plus de travail à chaque fois est presque cent pour cent. Les produits que je connais sont très bien attentionnés sur la compatibilité, car personne n'utiliserait ou la mettrait la mise à jour si elles ne le feraient pas et ce serait suicide.
+1 pour "wrappite". Googling ça soulève un seul résultat - cette page :)
Utiliser des interfaces d'emballage effectuez effectivement des tests unitaires beaucoup plus facilement, mais ce qui est tout aussi important, il permet d'utiliser des simulacres.
comme exemple, Le cadre de Prism pour Silverlight et WPF définit une interface plus tard, vous pouvez passer IloggerfaCade avec une méthode simple nommée journal . Utilisation de ce concept, voici comment je définis un enregistreur moqueur (en utilisant MOQ ) dans mes tests de mon unité : loggermock.Object à l'objet testé via constructeur ou propriété ou configurer un injecteur de dépendance qui l'utilise.
Je n'ai jamais vraiment compris cet argument car il est possible de se moquer de classes abstraites et concrètes ainsi que des interfaces. Je suis d'accord pour dire qu'il vaut mieux simuler des interfaces.
On dirait que vous pensez à emballer la mise en œuvre de l'exploitation forestière et le partage avec des équipes différentes. Sur la base de ce voici quelques avantages et les inconvénients.
J'ai enveloppé une partie de Enterprise Library avant et je ne pense pas que beaucoup de valeur ajoutée. Je pense que vous seriez mieux:
non sinon.
Définition de l'interface que votre application utilisera pour tous les objectifs de journalisation / entrepreneur / ... est le travail de base ici. L'écriture de l'emballage est simplement un moyen de faire appliquer le compilateur de cette interface plutôt que de la mise en œuvre réelle.