.NET Open Space Süd 2009 in Ulm - Inversion of Control/Dependency Injection

Nach dem "Kampf" von Castle Monorail vs. Microsoft MVC geht es heute um Inversion of Control bzw. Dependency Injection. Hier also meine Notizen zu diesem spannenden und häufig unterschätzten Thema:

• Klasse bezieht von ihr genutzte Klassen "von außen"
• Nutzung von Interfaces statt konkreter Implementierung
• Zuweisung des konkreten Objektes "von außen" - manuell oder per IoC-Container
• Konfigurationsstrategien für den Container
  • via XML - aufwändig, bäääh!
  • Objekte einzeln und "von Hand" hinein packen
  • relevante Objekte per Reflection aufsammeln (+ Sonderfälle explizit zuweisen)
    • StructureMap (gut strukturiert)
    • WindsorCastle (wenn man schon Monorail oder ActiveRecord nutzt)
    • Unity
    • Ninject
    • Spring
    • "von Hand" per Attribut
• Constructor injection: wenn keine Default-Implementierungen vorhanden sind
• Setter injection: praktisch, da nur bei Bedarf Default-Implementierungen überschrieben werden
• Performance: Zeitverlust durch IoC im Vergleich zu new ist verschwindend gering im Vergleich zur Lebenszeit des Objektes
• IoC hilft, Singletons zu erzeugen (die im Vergleich zum "normalen" Pattern sogar überschrieben werden können)
• Idealfall: alles wird injiziert
  • Attribute sind nicht injizierbar - Ausweg bietet CommonServiceLocator
• Container lässt sich beim Testen auch ausmocken