IoC Container Anwendbarkeit / Demonstration von Szenarien?

Question

Viele Leute im .NET-Umfeld haben Castle Windsor aufgegriffen und implementieren es in ihren Projekten, und seit einem Jahr kämpfe ich damit, herauszufinden, warum IoC-Container als allgemeine "Best Practice" behandelt zu werden scheinen? Ich habe eine Menge Zusammenfassungen und kurze Erklärungen über das Warum von Windsor und dergleichen gelesen, aber jede einzelne von ihnen ist in der Tat abstrakt und scheint für die meisten Projekte, mit denen ich zu tun hatte, nicht praktikabel zu sein, und doch bin ich in letzter Zeit auf viele Projekte gestoßen, die Windsor verwenden, und ich verstehe nicht, warum.

C#/.NET unterstützt von Haus aus schnittstellenbasierte Kodierung, abstrakte Objekte, Delegierte und Ereignisse. Man kann IoC direkt aus der Kernsprache heraus implementieren und mit Reflection und Ähnlichem unbekannte Instanzen instanziieren, die bekannte Schnittstellen implementieren, ohne auf IoC-Containerbibliotheken zurückgreifen zu müssen.

Bei der Anwendung von YAGNI/AYGNI (Are You Going To Need It?) habe ich das Gefühl, dass Windsor überstrapaziert wurde. Ich kann sicherlich die Vorteile eines IoC-Containers sehen, aber ich habe das Gefühl, dass diese Vorteile auf Kosten zusätzlicher Abhängigkeiten und Metadaten gehen (IoC-Container-spezifische Attribute und Methoden, die im Kerncode aufgerufen werden, .config-Dateien, die überall verstreut sind, app.config/web.config, die mit Binding-Tags gefüllt sind, die die Bearbeitung der .config-Datei erschweren, usw.), so dass ich versuche, den Kompromiss zu finden.

Allerdings akzeptiere ich die Möglichkeit, dass ich ALLE dieser Beobachtungen / Aussagen auf Unwissenheit, da ich noch nie stark mit einem Projekt, das Windsor oder andere IoC-Container-Bibliothek verwendet beteiligt gewesen. Was ich wirklich brauche, ist, dass jemand ein "durchschnittliches" oder "typisches" Projekt demonstriert, in dem eine IoC-Container-Bibliothek verwendet wurde, und warum dies angeblich eine "Best Practice" ist, wenn es mir so vorkommt, als würde es ein ansonsten sauberes Projekt mit Abhängigkeiten und Metadaten unordentlich machen.

Wenn jemand Blogbeiträge, Artikel oder Bücher kennt, die mich aufklären können, wäre das großartig.

(Ich argumentiere nicht um des Argumentierens willen, sondern weil ich wirklich wissen möchte, ob ich mich in Bezug auf IoC-Container weiterbilden sollte).

Answer 1

Es ist keine direkte Antwort auf Ihre Frage, weil ich nicht mit Castle-Windsor vertraut bin, und ich bin kein IoC-Experte, aber aus meiner Erfahrung mit der Java-Version von Spring kann ich sagen, dass (ich spreche über Spring hier, so kann es nicht der Fall mit Castle-Windsor sein) Es ist nicht nur der Dependency-Injection-Teil, der es großartig macht, sondern auch das Framework selbst: deklaratives Transaktionsmanagement, eingebautes Sicherheits-Framework, ORM-Unterstützung, eingebautes MVC-Web-Framework, RMI, Web-Services, E-Mail, AOP, etc. Und das alles lässt sich sehr gut mit IoC integrieren, und das Framework nimmt Ihnen in den meisten typischen Szenarien wirklich viel Arbeit ab.

Und Autowiring mit Annotationen + IDE-Unterstützung (z.B. IntelliJ IDEA für Spring) entschärft meiner Meinung nach das Problem der Konfigurationsdateien.

Ich weiß nicht, ob Castle-Windsor ist alles außer IoC-Container, aber wenn es ist, vielleicht ist es einfach noch nicht da in Bezug auf den Reichtum der Funktionalität als ein Rahmen.

Answer 2

Es scheint, als wollten Sie die Antwort auf diese Frage

Wenn das System so schwierig einzurichten ist, wie Sie sagen, dann ist es natürlich nicht viel wert, wenn Sie es warten müssen. Das ist ein wichtiger Punkt, den man beim Einsatz einer neuen Technologie bedenken sollte. Manchmal ist das alte, langweilige Zeug gerade wegen dieses Faktors viel besser.

Castle Windsor verwendet Reflexion selbst, so dass es wirklich ein Wrapper, um die Dinge zu tun, wie Sie sowieso wollen. Wenn Sie ein System entwickeln können, das einfacher zu bedienen ist als CW, dann sollten Sie das tun, auch wenn es Sie anfangs Zeit kostet. Diese Kosten werden durch die Lernkurve von CW ausgeglichen, so dass es nicht so ist, als würde man das Rad neu erfinden.

Sie tun sich selbst sagen dass IoC nicht für kleine Projekte geeignet ist,

Außerdem können je nach Art der Komplexität des Projekts kann ein IoC Container ein Overkill sein. [ ] bei mittelgroßen bis großen Projekten zu verwenden.

Answer 3

Ich glaube nicht unbedingt, dass ein IoC-Container in allen Fällen gut ist. Aber er kann es definitiv sein. Wenn Sie Dependency Injection oder Service Locator für den Umgang mit Abhängigkeiten verwenden, haben Sie ohnehin schon einen langen Weg hinter sich, aber ein IoC-Container kann dabei helfen, Dinge automatisch zu erledigen, Ihnen Unterstützung für fortgeschrittenere Szenarien bieten usw.

Ich habe vor einiger Zeit in einem Blogbeitrag versucht, es für mich zu definieren:

Ein Inversion of Control (IoC)-Container ist eine nicht-invasive, konfigurierbare, intelligente Fabrikkomponente

Zerlegt man diese Definition in Teile, erhält man

• Factory, weil sie für die Erstellung von Objekten für Sie zuständig ist.

• Intelligent, weil es weiß, welche Abhängigkeiten Sie haben, und sie für Sie rekursiv erstellt.

• Konfigurierbar, da Sie die Verwendung durch Code oder Konfigurationsdateien konfigurieren können.

• Nicht-invasiv, da die verwendeten Objekte nichts über den Container wissen müssen.

  -

Wenn Sie es richtig mit dem Dependency-Injection- oder Service-Locator-Muster verwenden, erhalten Sie einige wirklich praktische Vorteile. Sie müssen nicht unbedingt einen externen Container wie Winsor verwenden, aber das bietet Ihnen einige zusätzliche Vorteile.

Sie können viel weniger Code für die Instanzierung neuer Objekte schreiben. Und wenn Sie an komplexere Objekthierarchien denken, kann ein IoC-Container dabei helfen, die gesamte Kette automatisch für Sie zu erstellen. Das kann sehr mächtig sein.

Sie können während des Testens problemlos Mocked-Versionen der Objekte hinzufügen (wenn Sie DI und/oder SL verwenden). Wenn Sie zum Beispiel einen Service-Locator für sich selbst erstellen, wäre dies ebenfalls eine Lösung.

Wenn Sie die Abhängigkeiten, die Sie in den Konstruktor injizieren wollen, ändern, müssen Sie nicht unbedingt viel Code umstrukturieren.

Durch die Tunnelung von Abhängigkeiten über eine Quelle ergeben sich verschiedene Vorteile: Decorators, Interceptors, Proxies, sowie die Handhabung von Objekt-Lifestyle. Mit einem Container wie Windsor können Sie auf diese Weise einige schwierige Dinge wirklich einfach und mit extrem wenig Kopplung erledigen

Sie können sein Konzept der Einrichtungen für eine reibungslose Integration mit z.B. NHibernate nutzen

Answer 4

Ich schlage vor, dass Sie sich Folge 2 des Software Engineering Radio-Podcasts anhören. Es ist eine ganze Folge über Dependency Injection. Dependency Injection ist die bekannteste Anwendung von Inversion of Control Frameworks. Ich würde auch empfehlen, sich die DotNetRocks-Folge 362 mit John Kovacs anzuhören. Hier ist eine Abschrift der Sendung.

Ein Nebeneffekt von IOC ist nun die verbesserte Testbarkeit. Die Verwendung von IOC-Containern wie Castle Windsor hilft bei der Entkopplung von Abhängigkeiten. Diese Entkopplung sorgt für bessere Unit-Tests.

Die meisten IOC-Frameworks verfügen auch über Möglichkeiten zur Erleichterung der aspektorientierten Programmierung. Wenn Sie sich also dafür interessieren, können IOC-Container-Frameworks Ihnen dabei helfen.