8

Mam 4 projekty:Dependency Injection i struktura projektu dla aplikacji konsolowych

rdzeniowy (IServer):

  • systemowe
  • System.Core

DependencyResolver:

  • Rdzeń
  • StructureMap

Infrastructure (serwis):

  • Rdzeń
  • zależność zewnętrzna

konsoli:

  • Rdzeń
  • DependencyResolver

Requierements:

Próbuję użyć StructureMap tylko w DependencyResolver. Ponadto aplikacja Console nie powinna wiedzieć nic o infrastrukturze.

Kiedy nie chcę odwoływać się do StructureMap w mojej aplikacji Console, muszę zbudować ServiceLocator.

W DependencyResolver Mam inicjującego, który jest odpowiedzialny za wywołanie StructureMap rzeczy rejestru (rejestru)

W mojej aplikacji konsoli chcę uzyskać instancję. W tym celu muszę odwołać się do StructureMap. Innym sposobem byłoby napisanie małego wrappera o metodach StructureMaps.

Czy istnieje inny lepszy sposób oddzielenia konsoli od StructureMap?

+0

Brzmi trochę ponad zaprojektowane. Jak wygląda twój kod? Dlaczego potrzebny jest lokalizator usług, jeśli narzędzie do rozwiązywania zależności już hermetyzuje mapę struktury? – SimonC

+0

Czy widziałeś http://bootstrapper.codeplex.com/ –

+0

Rozdzielacz zależności nazw nie jest najlepszym wyborem w odniesieniu do tego, za co składnik jest odpowiedzialny. Obecnie jedynym obowiązkiem jest rejestrowanie zależności. Tak więc moje pytanie dotyczy bardziej rozdzielczej części Dependency Injection. – Rookian

Odpowiedz

17

Podczas gdy widzę przyczynę oddzielenia rejestru IoC, rozwiązania, zwolnienia z implementacji aplikacji, nie widzę powodu, dla którego kontener IoC nie powinien znajdować się w aplikacji konsoli (główny skład) i zamiast tego implementacja aplikacji w innym zespole.

ten sposób aplikacja konsola jest bardzo proste:

  1. Tworzenie pojemnik
  2. Załaduj konfiguracja pojemnik
  3. Resolve Aplikacji
  4. prowadzony Zaproszenie od zastosowania i przekazywać argumenty konsoli wraz
  5. wyrzucaj pojemnik, gdy aplikacja opuszcza metodę uruchomienia

SM wyglądać o tak:

public void Main(params string[] args) 
{ 
    using (var container = new Container()) 
    { 
     container.LoadAllConfigurationModules(); 
     container.AddRegistry<SomeRegistry>(); 
     container.GetInstance<Application>().Run(args); 
    } 
} 

rzeczy nie można utworzyć przy starcie utworzyć interfejs fabrycznego montażu w swojej aplikacji:

interface ISomeFactory { ISomeDependency CreateSomeDependency() } 

i wdrożyć ten interfejs w aplikacja konsolowa poprzez wstrzyknięcie pojemnika i użycie go do rozwiązania instancji. Wydaje mi się, że implementacja SM wygląda następująco:

public class SomeFactory : ISomeFactory 
{ 
    public SomeFactory(IContainer sontainer) { this.container = container; } 
    ISomeDependency CreateSomeDependency() { this.container.GetInstance<ISomeDependency>(); } 
} 

Inne pojemniki IoC mają nawet funkcję do automatycznego wdrażania tych fabryk interfejsów.

+0

Dzięki rozwiązaniu musisz odwołać się do wszystkich bibliotek w aplikacji konsoli. Ponieważ główny składnik leży bezpośrednio w klasie głównej. – Rookian

+6

Tak, to prawda. Ale gdzie jest problem? Ten zespół ma dokładnie jeden cel - ładowanie! –

+0

ah ok. Twoje drugie zdanie jest ważne. To ma sens. – Rookian

Powiązane problemy