Le StaticFactory <T> dans codecampserver est-il un modèle bien connu?

Question

Le code source CodeCampServer contient un StaticFactory générique. Je suppose que c'est un élément clé du mécanisme de la façon dont le cadre fonctionne bien avec l'injection de dépendances.

Les sous-classes utilisent DefaultUnconfiguredState pour fournir un accès statique à, par exemple, un état non configuré par défaut que le mécanisme de résolution de dépendance peut remplacer par du travail.

Je n'ai pas été en mesure de trouver toute la documentation pour cette ...

Y at-il une bonne explication dans the book? (J'attends la livraison d'Amazon ...)

... ou quelqu'un d'autre peut fournir un bon commentaire sur ce que c'est et si je serais sage d'adopter ce modèle (si c'est un ...)?

Mise à jour

Depuis Jeffrey Palermo a répondu à cette question, je vois que dans le ce modèle/style (travail en cours) manuscrit pour MVC2 en action est discutée et illustrée à l'aide d'une usine qui est utilisé pour localiser un référentiel afin de garder la couche de domaine ignorant des problèmes de persistance. (Voir chapter 23).

Par défaut, l'utilisation de cette usine jette une exception:.

« la connaissance de la façon de créer le référentiel ne réside pas avec l'usine Cette usine représente simplement la capacité de revenir le référentiel "

L'exemple aurait pu utiliser l'un des mécanismes suivants pour initialiser une implémentation concrète de l'interface du référentiel. Dans l'exemple du livre, ils choisissent de ne pas utiliser un conteneur IOC à des fins de simplicité et de le fournir explicitement dans une logique de démarrage.

« L'important est que ni le projet de base, ni le projet de l'interface utilisateur doit faire référence au projet ou les bibliothèques Infrastructure qui sont purement infrastructurel dans la nature . Nous avons gardé NHibernate complètement sur le côté si que le reste de l'application ne se soucie pas comment les données accès se passe »

Un dernier point à noter sur le code exemple dans ce nouveau chapitre est que t L'usine n'est plus statique (du moins en ce qui concerne l'interface externe).

Update 2

M. Palermo blogué un peu plus sur this particular style of Abstract Factory (voir le implementaion de OrderShipperFactory). Je pourrais également just consider 'Manual Dependency Injection' (Oncle Bob).

Mise à jour 3 - Mars 2016

Il y a another example of it here, bien que Jeffrey est explicite à ce sujet étant le code de démonstration, et le commentaire indique que cela serait configuré dans ce que Mark Seeman appellerait un Composition Root (c.-à démarrage de l'application -up)

J'ai découvert ce dans l'article de Jeffrey "Onion Architecture: Part 4 - After Four Years"

Answer 1

Bonne question. Je ne l'aime pas non plus. Il devrait vraiment être nommé "StartupFactoryConfiguration", mais il est sur la liste refactor.

Nous avons joué avec cette idée comme un moyen de configurer DI pour les endroits qui n'étaient pas sous l'injection du constructeur via le conteneur.

Il s'en ira. Je ne sais pas quel est l'anti-pattern (quel nom?), Mais StaticFactory va mourir.

---

Maintenant, il a été renommé à partir de ce matin. C'est maintenant AbstractFactoryBase. Il s'agit d'une implémentation du modèle Abstract Factory: http://en.wikipedia.org/wiki/Abstract_factory_pattern

La mise en œuvre de l'usine consiste à appeler un contraindre IoC, mais elle permet l'accès à partir d'une place dans le code sans une référence d'assemblage à l'ensemble du conteneur IoC.

Cordialement, Jeffrey Palermo

Answer 2

Tout statique est un ennemi de DI.

Cette StaticFactory ressemble à une implémentation du modèle (anti-) Service Locator. Je considère Service Locator comme un anti-pattern, car il est totalement opaque à l'utilisateur de l'API dont les dépendances doivent être en place; ainsi, on pourrait facilement invoquer des méthodes sur des objets dans un contexte où le localisateur de service serait lancé, et l'API ne vous donne absolument aucune idée que c'est le cas.

Une bonne DI comme une utilisation abondante de Constructor Injection est une bien meilleure alternative.