Ist das staticFactory in CodeCampServer ein bekanntes Muster?

Question

Der CodeCampServer -Quellcode enthält einen generischen StaticFactory.

Ich vermute, dass dies ein Schlüsselstück des Mechanismus ist, wie das Gerüst bei der Abhängigkeitsinjektion gut spielt.

Unterklassen, von denen die standardmäßige State für den statischen Zugriff auf einen nicht konfigurierten Zustand für sich selbst, den der Abhängigkeitsauflösungsmechanismus durch Arbeitsmaterial ersetzen kann, verwendet wird.

Ich konnte keine Dokumentation dafür finden ...

Gibt es eine gute Erklärung in das Buch? (Ich warte auf die Lieferung von Amazon ...)

... oder kann jemand anderes einen guten Kommentar geben, was das ist und ob ich dieses Muster übernehmen würde (wenn es eins ist ...)?

Aktualisieren

Da Jeffrey Palermo auf diese Frage antwortete, sehe ich, dass dieses Muster/Stil im (Arbeit in progress) Manuskript für MVC2 in Aktion mithilfe einer Fabrik diskutiert und illustriert wird von Beharrlichkeitsbedenken. (sehen Kapitel 23).

Standardmäßig bringt die Verwendung dieser Fabrik eine Ausnahme aus:

"Das Wissen, wie das Repository erstellt wird, befindet sich nicht in der Fabrik. Diese Fabrik repräsentiert lediglich die Fähigkeit, das Repository zurückzugeben."

Das Beispiel hätte einen von mehreren Mechanismen zur Initialisierung einer konkreten Implementierung der Repository -Schnittstelle verwenden können. In dem Beispiel in dem Buch entscheiden sie sich dafür, einen IOC-Container nicht aus Einfachheit zu verwenden und es in einer Startlogik ausdrücklich zu bieten.

"Wichtig ist, dass weder das Kernprojekt noch das UI Datenzugriff erfolgt "

Ein letzter Punkt, der zum Beispielcode in diesem neuen Kapitel beachtet wird, ist, dass die Fabrik nicht mehr statisch ist (zumindest nicht, was die extern ausgerichtete Schnittstelle betrifft).

Update 2

Herr Palermo hat noch etwas mehr darüber gebloggt Dieser besondere Stil der abstrakten Fabrik (Siehe die Implementierung von Bestellungen).

Ich könnte es auch Betrachten Sie einfach "manuelle Abhängigkeitsinjektion" (Onkel Bob).

Update 3 - März 2016

Es gibt Ein weiteres Beispiel dafür hier, Obwohl Jeffrey explizit über diesen Demo -Code ist und der Kommentar zeigt, dass dies in dem, was Mark Seeman als nennen würde, konfiguriert werden würde Kompositionswurzel (dh beim Anwendungsstart)

Ich habe dies in Jeffreys Artikel entdeckt "Zwiebelarchitektur: Teil 4 - Nach vier Jahren"

Answer 1

Gute Frage. Ich mag es auch nicht. Es sollte wirklich "StartupFactoryConfiguration" genannt werden, aber es steht auf der Refactor -Liste.

Wir haben mit dieser Idee herumgespielt, um DI für Orte einzurichten, die nicht über den Container unter Konstruktorinjektion standen.

Es wird verschwinden. Ich weiß nicht, was das Anti-Muster ist (welcher Name?), Aber staticFactory wird sterben.

---

Jetzt wurde es heute Morgen umbenannt. Es ist jetzt AbstractFactoryBase. Es handelt sich um eine Implementierung des abstrakten Fabrikmusters: http://en.wikipedia.org/wiki/abstract_factory_pattern

Die Implementierung der Fabrik besteht darin, am Ende einen IOC -Kontrainer aufzurufen, ermöglicht jedoch den Zugriff von einem Ort im Code ohne Assembly -Referenz auf die IOC -Containerbaugruppe.

Grüße, Jeffrey Palermo

Answer 2

Alles statisch ist ein Feind von DI.

Diese statische Faktorik sieht aus wie eine Implementierung der Service Locator (Anti-)-Muster.

Ich betrachte Service Locator als Anti-Muster, da er für den Benutzer der API, die Abhängigkeiten benötigen, völlig undurchsichtig ist. Man könnte also leicht Methoden auf Objekten in einem Kontext aufrufen, in dem der Service -Locator werfen würde, und die API gibt Ihnen absolut keinen Hinweis darauf, dass dies der Fall ist.

Ordnungsgemäße DI wie z. Konstruktorinjektion ist eine viel bessere Alternative.