2009-05-18 5 views
0

Ich habe in letzter Zeit mit Castle Windsor herumgespielt und realisiert, dass ich damit ein containerähnliches Objekt, das ich momentan benutze, unterstützen kann. Bis jetzt habe ich nur Informationen über eine Anwendung gelesen, die nur eine Container-Instanz pro Anwendung hat. Ist es richtig, viele Container pro Anwendung zu haben, wenn diese Container unterschiedlichen Ebenen angehören?Ist es richtig, viele Castle Windsor Container pro Anwendung zu haben, wenn diese Container zu verschiedenen Ebenen gehören?

Der Grund, warum ich frage, ist, weil ich Windsors Abhängigkeitsauflösung und XML-Konfiguration für mein eigenes containerähnliches Objekt nutzen möchte. Ich verwende derzeit die Windsor-Integration mit MonoRail und es schien nicht richtig zu sein, Komponenten zu mischen, die nichts mit MonoRail und seiner Controller-Ebene zu tun haben. Mein zweiter Container hätte eine eigene Konfigurationsdatei und hätte keine Kenntnisse über MonoRail und den Container, den er verwendet. Es befindet sich vollständig in einer anderen Ebene und würde letztendlich als Abhängigkeit für MonoRail-Controller registriert. Ich habe das Gefühl, dass das Umgehen von Container-Instanzen vermieden werden sollte, also ist dies der richtige Weg, dies zu vermeiden?

Antwort

2

Persönlich habe ich kein Problem mit nur einem Container. Schließlich kennen Ihre MonoRail-Controller nur die Dienste/Schnittstellen, die sie benötigen, damit sie nicht über die inneren Komponenten anderer Ebenen Bescheid wissen müssen.

Wenn Sie immer noch nicht wollen, Ihre inneren Komponenten so sichtbar für den Rest der App machen, sind hier ein paar Ideen:

  • Wickeln Sie Ihre zugehörigen Komponenten in facilities. Dies wird Ihnen helfen, die Konfiguration Ihrer inneren Komponenten zu vereinfachen und sie privat zu halten.
  • Delegate Komponente Instanziierung zu Ihrem Container-ähnlichen Objekt, Fabriken oder subdependencies Resolvern mit (ref1, ref2, ref3)
  • Verwenden Kind Containern. Ich habe sie nie ausprobiert, aber es sieht so aus, als könnte es in dieser Situation helfen (siehe ref1, ref2, ref3).

Was auch immer Sie tun, Sie nicht wollen jede Komponente haben, direkt auf den Behälter erreichbar. Wenn überhaupt, halte es in deinem "Klebecode".

+0

Danke für die Links. So wie es jetzt aussieht, habe ich keine Komponenten, die auf den Anwendungscontainer zugreifen. Derzeit habe ich eine Schnittstelle für meinen benutzerdefinierten Container, dessen Implementierung eine Instanz eines Windsor-Containers speziell dafür umschließt. Scheint viel einfacher auf diese Weise, als Subresolver, Einrichtungen oder Kindercontainer aufzubauen. Außerdem hat es eine eigene Konfiguration und ich vermeide es, Container-Instanzen herumzugeben. Warum den anwendungsweiten Container erweitern, wenn eine private Instanz so viel einfacher ist? –

+0

Ich dachte du wolltest deinen Container in Windsor wickeln, nicht umgekehrt ... –

+0

Nein, mein Container hätte eine Instanz eines Windsor Containers. Mein benutzerdefinierter Container würde dann die Windsor-Auflösung und die XML-Konfigurationsbits nutzen. Ich würde gerne wissen, ob ich mit dieser Herangehensweise völlig daneben liege, das ist alles. Muss ich meine Frage neu formulieren, um sie klarer zu machen? –

0

Ich glaube nicht, dass es so eine gute Idee ist, viele unabhängige Container zu haben. Sie können jedoch einen anwendungsweiten Mutter Container und Kind Container mit engerer Anwendungsbereich haben.

+0

Welchen Vorteil haben Kindercontainer gegenüber unabhängigen Containern? Beachten Sie, dass in meinem Fall nur eine Container-Instanz in der HttpApplication vorhanden ist, um Abhängigkeiten von MonoRail-Controllern aufzulösen. Meine andere Container-Instanz wäre nur für meine benutzerdefinierte Container-Implementierung sichtbar. –

0

Sie können wahrscheinlich Kindkerne verwenden? Aber ich mag die Idee nicht sehr.

Verwandte Themen