2016-04-11 5 views
0

Ich weiß, dass ASP.NET MVC DependencyResolver hat. Wie erhalten Sie den ähnlichen anwendungsweiten Zugriff auf IUnityContainer in Nicht-MVC-Anwendungen? Öffentliche statische Klasse zu verwenden ist Unsinn. Hier ist mein Anwendungsfall:Zugriff auf IUnityContainer in Nicht-MVC-Anwendungen?

public partial class App : Application 
{ 
    public App() 
    { 
     IUnityContainer container = new UnityContainer(); 
     container.RegisterInstance(new MyClass()); 
    } 
} 
public class MainViewModel 
{ 
    public MainViewModel() 
    { 
     IUnityContainer container = ??? 
     if (container.IsRegistered<MyClass>()) 
      DoSomething(); 
    } 
} 
+0

Was genau meinen Sie mit "Nicht-MVC"? Es gibt viele Möglichkeiten, wie UWP, WPF, Console App und mehr – Domysee

+0

Ich suche eine Lösung, die für alle Arten von .Net-Anwendungen gilt. –

+0

Es gibt keine Lösung, die mit allen Arten von .Net-Anwendungen funktioniert. Es gibt Lösungen für jeden, aber sie sind alle unterschiedlich. – Domysee

Antwort

0

Ich glaube nicht, gibt es eine Möglichkeit, anders als von Ihnen angegebenes IOC und DI für nicht MVC-Anwendungen zu implementieren. Aber wenn es einen Weg gibt, dann werden alle Vorschläge geschätzt.

1

Wenn Sie nach einer Lösung suchen, die für die meisten Anwendungen geeignet ist, können Sie die Komponente auf höchster Ebene registrieren und dann beheben. Solange Sie die Instanz auflösen, löst Unity die Abhängigkeiten auf (z. B. IUnityContainer).

class Program 
{ 
    static void Main(string[] args) 
    { 
     Console.WriteLine("Registering dependencies ..."); 

     var container = new UnityContainer(); 
     container.RegisterType<ProgramStarter, ProgramStarter>(); 

     // Do other registrations. 
     var program = container.Resolve<ProgramStarter>(); 

     // Since ProgramStarter was resolved using Unity it will also resolve the container. 
     program.Run(); 
    } 
} 

public class ProgramStarter 
{ 
    public ProgramStarter(IUnityContainer container) 
    { 
     // Do something with container. 
    } 

    public Run() 
    { 
     // Do stuff. 
    } 
} 

Oder ein Beispiel für WPF:

IUnityContainer container = new UnityContainer(); 
// Do registrations. 
var window = container.Resolve<MainWindow>(); 
window.Show(); 

MainWindow wird nun in der Lage sein, sowohl die Behälter und andere Abhängigkeiten zu lösen.

Auch haben einen Blick auf diese Frage: Where to place and configure IoC container in a WPF application?

Als Nebenbemerkung ich meinen Container in der Regel als eine statische Instanz halten, und viele andere Implementierungen die gleiche Sache gesehen. Ich finde es bequem, es zu benutzen, wenn Sie sich in einer Situation befinden, in der es nicht möglich ist, es zu lösen.

public static class IocContainer 
{ 
    private static readonly Lazy<IUnityContainer> Container = new Lazy<IUnityContainer>(() => 
    { 
     var container = new UnityContainer(); 
     // Possibly do registrations here as well... 
     return container; 
    }); 

    public static IUnityContainer Instance 
    { 
     get { return Container.Value; } 
    } 
} 
+0

Danke für Ihre wertvollen Einblicke. Ist diese Lösung jedoch abhängig von einer Schnittstelle als Parameter des Konstruktors? Wenn ja, funktioniert es nicht, wenn die Klasse mit einem parameterlosen Standardkonstruktor instanziiert wird. Diese Lösung funktioniert beispielsweise nicht für ViewModel, das einen parameterlosen Standardkonstruktor benötigt, der aus der .xaml-Datei aufgerufen wird. Wie kann ich intuitiv vom parameterlosen Standardkonstruktor auf IUnityContainer zugreifen? –

+0

Ja, die Lösung basiert auf der Verwendung von Unity für die Abhängigkeitsinjektion, die Schnittstellen im Konstruktor verwendet. Ich kenne keinen anderen Weg, den Container zu holen, ohne ihn wie in der Antwort vorgeschlagen auf eine statische Variable zu setzen. – smoksnes

+0

Ich verstehe nicht, warum der DependencyResolver nicht auf andere Projekte als ASP.NET verallgemeinert werden kann ... Gibt es einen Einblick darauf? –