Verschwendet IoC mit Konstruktorinjektion in asp.net mvc-Controller Ressourcen?

8

Ich bin mir nicht sicher, ob es nur ich, aber ich habe das Gefühl, dass Konstruktor Injektion in ASP.NET MVC-Controller unnötigen Ressourcenverbrauch verursacht.

Komponenten, die nicht verwendet werden für eine bestimmte Webanfrage müssen noch erstellt werden, wenn Controller erstellt werden. Es ist, als würde ich Milch und Saft kaufen, wenn ich nach Milch dürste, und dann schmeiße ich einfach den Saft weg.

Vergleichen Sie diese Beispiele von Konstruktorinjektion und Service Locator für Controller, um meine Bedenken zu klären.

Konstruktor Injection, Stand-Deps werden erstellt, aber nur einer wird verwendet.

%Vor%

Service Locator, jedes dep wird nur erstellt, wenn es verwendet wird.

%Vor%

BITTE BEACHTEN , dass ein IoC-Container (der aus vielen Gründen vorteilhaft ist) weiterhin für das Service Locator-Muster verwendet werden kann. Ich möchte nicht, dass dies eine Diskussion um IoC und Container-Frameworks ist, und auch keine anderen Vorteile der Konstruktorinjektion (klare Sichtbarkeit von Abhängigkeiten etc.). Es ist das Konstruktor-Injektionsmuster und wie es Ressourcen in ASP.NET MVC-Controller-Situationen verschwendet das ist mein Anliegen.

Ich denke, die Hauptfrage ist hier: Ist Service Locator für das obige Szenario eine bessere Lösung (ASP.NET MVC-Controller)?

    
Max Wikström 02.04.2013, 10:09
quelle

2 Antworten

8

Wenn die Objekterzeugung Ihr Flaschenhals ist, sind Sie entweder in einer sehr guten Situation (alles andere funktioniert wie ein Zauber, so dass die & lt; 1 ms Operationen zählen) oder in einem sehr schlechten (Ihre Konstruktoren machen etwas schweres Heben - was sie sollen nicht).

Mark Seemann hat das Thema hier bereits behandelt: Ссылка

  

In vielen Fällen ist das ein Performance-Hit, den du wegen dir machen musst   Ich brauche diese Kurse sowieso, aber manchmal mag es dich interessieren   Nehmen Sie diese Leistung zu früh. Ich behaupte jedoch, dass   In den allermeisten Fällen ist dieses Anliegen irrelevant.

Und lieferte eine mögliche Lösung, wenn es Ihnen immer noch wichtig ist (verzögerte Zweige).

    
motime 02.04.2013 10:25
quelle
2

Wenn Sie nicht etwas konstruieren wollen, das Sie nicht brauchen / verwenden, geben Sie etwas ein, das das konstruieren kann, was Sie brauchen.

Wenn Sie den Service Locator + DI in unserer Controller-Fabrik verwenden, können wir eine Dep Factory an die Steuerung übergeben und der Steuerung die Entscheidung überlassen, wofür sie die Fabrik fragen soll.

Ist das nicht der Grund, warum wir das Fabrikmuster haben?

Um Ihr Beispiel in der Frage zu überarbeiten, möchten Sie vielleicht so etwas machen ...

%Vor%

Dies ist sowohl effizient als auch eine gute Verwendung von Mustern.

Vom Standpunkt des Testens aus können Sie die übergebene IDepFactory vortäuschen, so dass sie immer eine Konstante zurückgibt, wenn Abfragen ein bekanntes Ergebnis zurückgeben, damit Sie bestätigen können, dass Ihre Logik in Ihrem Controller richtig funktioniert.

Aus der Sicht der Leistung würde ich denken, dass der Unterschied hauptsächlich von der Tiefe Ihrer Dependency-Stacks in jedem Fall abhängt. Vielleicht ziehen Sie es vor, keine Factory zu verwenden und beide Deps wie zuvor zu übergeben, wenn der Dependency-Stack ist sehr flach, da die Gewinne praktisch nichts sind.

    
War 24.03.2016 11:36
quelle