Die Trennung von Bedenken, die von IoC / DI-Frameworks geliefert werden, kann für ein großes Projekt nicht überschätzt werden, aber gibt es einen Platz für solche Techniken in einem kleinen Projekt?
Können Sie einige reale Anwendungen von IoC / DI-Frameworks teilen, die Sie für die Programmierung eines anderen kleinen / durchschnittlichen Projekts als nützlich erachtet haben?
Der Definition wegen:
Ein "kleines Projekt" enthält 100-1000 Zeilen Code (balpark, nur um eine Idee zu geben), es dauert 1-3 Tage, um zu codieren und die Lebensdauer der resultierenden Anwendung, bevor es weggeworfen wird oder die Dekomposition innerhalb ist 1 Woche - 5 Jahre nach der ersten Veröffentlichung (das ist dort wird es schwer, eine Linie zwischen klein / durchschnittlich / großes Projekt zu ziehen).
Danke.
Hängt davon ab, was Sie in Ihrer Implementierung für wichtig halten. Wenn Testbarkeit wichtig ist und wenn Sie dazu neigen, dem Prinzip der einfachen Verantwortlichkeit zu folgen (in kleinen oder großen Projekten), erhalten Sie im Allgemeinen etwas mehr Klassen, als Sie es wahrscheinlich sonst tun würden. Dies kann zu einem Aufruf wie
führen %Vor%Wenn du damit leben kannst und persönlich ich auch, in einer wegwerfenden App, dann brauchst du auf keinen Fall einen DI Container. Geh mit was auch immer dich glücklich macht. Prost.
Bearbeiten :
Im Laufe der Jahre habe ich festgestellt, dass TinyIoC ein guter Kompromiss für kleinere Projekte ist.
Für ein kleines Projekt wäre ich versucht, die Abhängigkeitsinjektion zu verwenden, aber kein Framework zu verwenden. Erstellen Sie einfach alle Abhängigkeiten in Ihrem Einstiegspunkt. Sie erhalten immer noch alle Vorteile der Testbarkeit, und Sie können später einen vollwertigen Container verwenden - aber Sie müssen sich nicht darum kümmern, den Container einzurichten, bis er tatsächlich nützlich ist.
Ich habe diesen Ansatz bei einigen kleinen Projekten verwendet und es hat sehr gut funktioniert. Natürlich hängt es davon ab, wie kompliziert Ihre Abhängigkeiten sind - ob sie Fabriken sein müssen, unterschiedliche Scoping-Einstellungen usw. - aber wenn es nur "Ich habe diese drei Dinge, die alle auf einen Authentifizierungsdienst angewiesen sind" ist, ist das ziemlich einfach.
>Aber gibt es einen Platz für solche Techniken in einem kleinen Projekt?
Auch in kleinen Projekten sollten Sie das IoC-Muster verwenden, um die Kopplung zwischen den Schichten zu schwächen und sie testbar zu machen. Immer mit Abstraktionen arbeiten. Ob Sie ein DI-Framework verwenden oder nicht, spielt keine Rolle. In kleinen Projekten können Sie die Abhängigkeiten einfach manuell tun, brauchen nicht wirklich einen Objektcontainer, um die Abhängigkeitsinjektion durchzuführen, aber wenn Sie es einen zweiten Gedanken geben, warum nicht?
Ich schreibe viele ähnlich große Projekte, 30-40 pro Jahr.
Ich verwende DI, aber erstelle meine eigene Factory-Klasse mit einer Resolve-Methode.
%Vor%Eine Abkürzung, die ich mache, besteht darin, dass ich die meisten Mitglieder virtuell mache, anstatt eine separate Schnittstelle zu erstellen.
Ich würde IOC nicht so sehr auf die Projektgröße beziehen wie:
Besonders die letzten beiden werden es viel einfacher machen, wenn Sie Ihren Code testen, den Sie brauchen (gut kann es mit geeigneten Werkzeugen aber ... vermieden werden). IoC.
Daher würde ich vorschlagen, keine DI-Container für Starter zu verwenden, aber definitiv verwenden IoC in Bezug auf Schnittstellen und Doppelkonstruktoren wie:
%Vor%Einfache Zwei-Ebenen-Abhängigkeiten lassen sich ohne den Einsatz von DI-Containern einfach manuell verwalten. Und wahrscheinlich auch schneller zu benutzen. Dies wird Ihren Code leicht testbar machen und vor allem daran denken, wenn Sie Bugs als Testfälle bereitstellen, die eine zukunftssichere Fehlervermeidung automatisieren.
Kleine Projekte mit einem Mehrwert im Geschäftsumfeld werden tendenziell häufig erweitert, da sie die Vorstellungskraft der Benutzer dazu bringen, die Dinge noch weiter zu verbessern. Unterschätzen Sie Ihr kleines Projekt also nicht. Es kann bald wachsen.
Warum sollte man keinen DI-Container für kleine Projekte verwenden? Je einfacher Ihre Code-Basis, desto einfacher ist es, einen Container zu verwenden, mein Rat ist, dass es eine einfache flüssige Schnittstelle für die Abhängigkeitsregistrierung bietet, oder einfach nur linq verwenden, dann haben Sie ziemlich viel mit einem wirklich kleinen Fußabdruck zu tun, der Ihren gesamte App:
%Vor%Das ist so einfach wie es für viele kleine Projekte sein muss. Die Idee ist ein Liner, der alle Typen in Ihrem Projekt mit einer Standardschnittstelle registriert (ich schreibe normalerweise eine Erweiterungsmethode auf "System.Type", um entweder eine benannte Schnittstelle, die erste Schnittstelle auszuwählen oder einfach selbst zurückzukehren). HINWEIS: Die meisten modernen IoC-Container verfügen über eine eigene Fluent-Schnittstelle, um diese Funktionalität bereitzustellen. Dies ist nur ein Beispiel.
Und hey, du bist jetzt für die Zukunft des unerwarteten Wachstums gerüstet, du kannst dir eine Menge "Neues" sparen und deine Anwendung groß oder klein entkoppeln.
Tags und Links .net c# dependency-injection inversion-of-control