2013-03-18 6 views
14

Ich versuche, die Verwendung eines IoC-Frameworks wie StructureMap zu verstehen, aber ich kann nicht umhin, zu denken, dass diese "Entwurfsmuster" nur Unsinn sind und Code nur noch komplexer machen.Was nutzt ein IoC-Framework in einer MVC-Anwendung?

Lassen Sie mich mit einem Beispiel beginnen, in dem ich denke, dass ein IoC etwas nützlich ist.

Ich denke, dass ein IoC nützlich sein kann, wenn es um die Instanziierung von Controller-Klassen in einem MVC-Framework geht. In diesem Fall denke ich über das .NET MVC-Framework nach.

Normalerweise wird die Instanziierung der Controller-Klasse vom Framework übernommen. Das bedeutet, dass Sie dem Konstruktor Ihrer Controller-Klasse keine Parameter übergeben können. Hier kann ein IoC-Framework nützlich sein. Irgendwo in einem IoC-Container geben Sie an, welche Klasse instanziiert und an Ihre Controller übergeben werden soll constructor, wenn die Controller-Klasse aufgerufen wird.

Dies ist auch praktisch, wenn Sie den Controller Unit testen möchten, weil Sie das Objekt, das an es übergeben wird, verspotten können.

Aber wie ich schon sagte, ich kann verstehen, warum Leute es für ihre Controller-Klassen verwenden möchten. Aber nicht außerhalb davon. Von dort an können Sie einfach normal Dependency Injection tun.

Aber warum nicht einfach tun es wie folgt aus:

public class SomeController 
{ 
    public SomeController() : this(new SomeObj()) 
    { 
    } 

    publiv SomeController(SomeObj obj) 
    { 
     this.obj = obj; 
    } 
} 

Jetzt müssen Sie keine 3rd party IoC-Framework verwenden, die auch eine geringere Einarbeitungszeit bedeutet. Da müssen Sie auch nicht in die Spezifikationen dieses Frameworks gehen.

Sie können das Objekt in Ihren Komponententests immer noch vortäuschen. Also auch kein Problem.

Das einzige, was Sie sagen können, ist, "aber jetzt ist Ihre Klasse eng gekoppelt zu SomeObj". Das ist wahr. Aber wen interessiert das schon!? Es ist eine Controller-Klasse! Ich werde diese Klasse nie wieder verwenden. Also warum in aller Welt sollte ich mir Sorgen um diese enge Kopplung machen ..? Ich kann das Objekt verspotten, das an es weitergegeben wird. Das ist das einzig Wichtige.

Warum sollte ich einen IoC verwenden? Verpasse ich wirklich den Punkt ...? Für mich ist das IoC-Muster nur ein überbewertetes Muster. Hinzufügen weiterer komplexer Schichten zu Ihrer Anwendung ...

+0

@HenkHolterman Nicht unbedingt, wenn jemand mit einem guten Argument kommt, warum mein Ansatz falsch ist und in welcher Art von Situation. Ich habe nicht vor mit jemandem zu streiten. Ich suche nur Rat in dieser Angelegenheit. – w00

+3

mögliches Duplikat von [Warum brauche ich einen IoC-Container im Gegensatz zu einem einfachen DI-Code?] (Http://stackoverflow.com/questions/871405/why-do-i-need-an-ioc-container-aso-opposed) -zu-geradlinig-di-code) –

Antwort

8

Sie bitten, eine gute Frage und in Ihrem Beispiel würde ich sagen, dass ein IoC würde/könnte Overkill, aber denken Sie nur daran, dass Ihr Code auf das Folgende erweitert wurde und Sie dann vielleicht den Vorteil sehen, einen IoC zu haben, der all das für Sie erledigt.

public class SomeController 
{ 
    public SomeController() : this(new SomeObj(new configuration(), new SomethingElse(new SomethingElseToo()))) 
    { 
    } 

    publiv SomeController(SomeObj obj) 
    { 
     this.obj = obj; 
    } 
} 
4

Es gibt mehrere Dinge, die ein IoC-Container für Sie tun kann.

Die offensichtlichste ist die Implementierung für die Abhängigkeiten schaffen, die an anderer Stelle sinnvoll ist, nicht nur in Controller - Wenn Sie ersetzen SomeObj mit SomeObj2 entscheiden, können Sie es nur an einer Stelle in tun, anstelle von 57 Plätzen.

Ein anderes befasst sich mit den Lebenszyklusproblemen, d. H. Sie können den Umfang eines Objekts angeben (Singleton, pro Thread, pro Anfrage, transient ...).

Zusätzlich kann der IoC-Container Ihre optionalen Abhängigkeiten einstellen (d. H.Eigenschaft Injektion), die diese ist einfacher als das Schreiben:

var svc = new Service(new MyRepository()) 
svc.Logger = logger; 
svc.XY = xy 
hier angegeben

und alle guten Gründe: Why do I need an IoC container as opposed to straightforward DI code?

2

Aber wen interessiert !? Es ist eine Controller-Klasse! Ich werde nicht wiederverwenden, dass Klasse, je ..

Dies ist ein guter Punkt, aber überlegen, wie Reiniger ist der Code, wenn Sie Abhängigkeiten verschachtelt sind, mit unterschiedlichen Lifecycles. Zum Beispiel können Sie ein Singleton auf Anwendungsebene haben, etwas, das "pro Anfrage" sein muss, und so weiter. Der IoC macht nur Ihren Code sauberer und einfach zu modifizieren.