Existe-t-il une solution moins verbeuse que l'utilisation du modèle Provider Factory?

Question

Lorsque .NET 2.0 est sorti, j'ai été très impressionné par le modèle Provider Factory utilisé pour plusieurs des services qui ont été déployés à ce moment-là ... et commencé à l'utiliser partout.

Mais je suis tombé sur des problèmes réels avec elle:

• Sur CE, il n'y avait pas de système de configuration, il ne pouvait pas facilement être porté à cet environnement (et donc provoquer fourches graves dans le code qui pourrait ai-je bien travaillé sur les deux frameworks avec seulement quelques modifications?)
• Je n'ai jamais trouvé de bonne réponse à la question de savoir comment s'assurer que le gestionnaire statique avait enveloppé toutes les méthodes des fournisseurs: le providerBase pouvait implémenter une interface, mais interfaces (AFAIK) ne peut pas être utilisé sur des méthodes statiques. Il y avait donc toujours un risque de divergence entre le fournisseur enveloppé et le gestionnaire statique.
• La quantité de code de la plaque de la chaudière a été projetée à travers le toit, et ma productivité a chuté de façon inverse à travers le sol. Je veux dire par là qu'au lieu de simplement appeler instance.Method();

j'appelais, mais par un Manager.DoWork statique(), qui invoquait DoWork() de son instance, qui habituellement a fini par être un code commun dans la classe ProviderBase, qui a vérifié les args, a fait un travail , et enfin appelé un InternalDoWork() abstrait, qui a été implémenté dans la classe CustomProvider ...

En d'autres termes ... une manière très tortueuse d'invoquer une méthode (3 à 4 méthodes, vérification de l'argument partout, non-clarté de où essayer/catch/log - in Manager ou ProviderBase? -etc

Donc, ma question est: y at-il un autre motif (s) que je peux regarder pour donner config config capacités d'uration, permettant un changement dynamique - enfin, au moins au redémarrage - du fournisseur de services? PS: J'ai beaucoup entendu parler de IoC/DOI ces derniers temps comme étant une solution peut-être plus rapide ... mais pas utilisé dans la production. Cela semble intéressant ... Mais ma première impression est que DOI semble avoir la permutation des services, configurable dans le fichier de configuration, mais pas la configuration des paramètres du fichier de configuration?

Merci!

Answer 1

Le bloc d'application Unity du groupe Microsoft Patterns and Practices est plutôt bon. Bien que probablement pas le seul ou le meilleur là-bas. En outre, le framework MEF est en train de parler de Microsoft en l'utilisant/l'intégrant dans Visual Studio 2010.

Answer 2

Je pense que vous voudrez regarder dans les bibliothèques d'Injection de Dépendance comme la suggestion de @ David Unity. Je préfère Autofac. Mais il y en a d'autres http://en.wikipedia.org/wiki/Dependency_injection.

Answer 3

Si vous voulez explorer l'injection de dépendance, je recommanderais les bibliothèques Ninject ou StructureMap. Il y a quelques questions StackOverflow about .NET IoC containers though, alors cherchez juste et vous trouverez beaucoup plus d'informations. En ce qui concerne votre question actuelle, la tendance semble être vers un modèle Composition-based, plutôt que Subtyping que le modèle Provider utilise. Cela semble correspondre plus étroitement à des choses plus récentes qui sortent de Redmond, tels que ASP.NET MVC. En mettant l'accent sur la composition, on entend un dessin décrivant les relations «a» entre les parties plutôt que les relations «est une».Ils ont tendance à se concentrer sur la définition de moins de détails contractuels et la mise en place d'implémentations spécifiques sur la façon de remplir le contrat, plutôt que sur la construction forcée (en utilisant des méthodes abstraites), ce qui est souvent le cas. mise en œuvre spécifique. Les deux approches ont des inconvénients (par exemple, la gestion des versions est souvent citée comme un défi avec une conception basée sur la composition en utilisant des interfaces), cela peut donc dépendre de ce que vous faites.

En général, je pense que l'injection de dépendances est meilleure pour le code d'application car composer votre application la rend souvent moins étroitement couplée que de définir un modèle d'héritage strict et facilite généralement le test unitaire. En outre, beaucoup de problèmes typiquement cités avec la composition sont moins importants pour le code de l'application que pour les frameworks (encore une fois, le versioning). La vérité est probablement quelque part au milieu, comme dans MVC, où les dépendances entre composants utilisent des interfaces simples (Composition) mais les classes de base implémentant des fonctionnalités communes sont également disponibles pour hériter et ne remplacer que les bits nécessaires. C'est pourquoi les conteneurs IoC ont tendance à aider ici parce qu'ils fournissent des moyens faiblement couplés pour qu'un système demande un composant sans avoir à connaître quoi que ce soit sur l'implémentation. Par exemple, DependencyResolver.GetInstanceOf<IUserRepository>().