Zu 1) Generell gilt bei DI immer: man sollte den Code so schreiben, dass man auch manuell seine Sachen zusammen stecken kann und nicht auf
RTTI "Magic" des DI Containers angewiesen ist (Mark Seemann nennt das immer
"poor mans DI".
Weniger würde ich hier als Grund die Vermeidung von Attributen sehen - wenn die
Unit dafür fehlt, wird immerhin eine Warning ausgegeben, die man auch leicht als Fehler markieren kann in den Einstellungen. Natürlich braucht man für ctor injection standardmäßig keine Attribute aber man kann sie trotzdem an verschiedenen Stellen einsetzen und spart sich u.U. eine Menge registrierungs Code (noch gibt es das nicht, aber in Zukunft plane ich eine automatische Registrierung aller Typen, die mit entsprechenden Attributen versehen sind)
Zu 2) Das ist ein komplexes Thema und kommt drauf an, welche Architektur du hier verwendest, MVP, MVC, MVVM, view first, model first, etc (einfach mal diverse Literatur zu lesen). Factories bieten sich aber auf jeden Fall für Forms an, welche nicht gleich zu Beginn da sind und evtl auch während einer Session niemals aufgerufen werden. Allerdings muss man bei Forms/Controls und dem DI Container natürlich auf das Memory Management achten. Wenn du ein Form als Interface im Container registrierst dann hat der Container keine Chance, da richtig zu verwalten, weils keine Referenzzählung gibt (außer du implementierst die selber als eine TRefCountedForm oder so). Als Singleton Registrierung würde noch gehen, wenn das Form nur einmal in der Anwendung instanziert wird.
Zu 3) In DSharp haben wir mal angefangen einen Caliburn.Micro (MVVM Framework aus .NET) zu portieren, die ganze Sache ist aber noch nicht rund und durch das Setzen der Prioritäten auf Spring4D für 2014 ist das erstmal ein wenig ins Hintertreffen geraten. Es gibt dort ein kleines Demo wie solch eine MVVM Anwendung aussieht - aber schonmal die Warnung vorweg, MVVM kann erstmal ziemlich verwirrend sein, grad wenn man alles mit
CoC macht.
Interessant, diese Frage nach dem "Durchreichen" taucht immer wieder in Verbindung mit DI auf. Egal ob Container oder "poor mans DI". Du reichst nix durch. Warum? Weil du ja auch nichts selber erzeugst. Du gibst nur eins ins andere hinein. Hierbei auch beachten, nur Abhängigkeiten hineingeben, die direkt von dieser Klasse benutzt werden. Natürlich kommen hier vermutlich vermehrt factories zum Einsatz, aber diese werden auch im
composition root erzeugt und an die entsprechenden Stellen verteilt.
Diese Antwort erklärt das auch ganz schön.
Und ja, wenn man "poor mans DI" macht, dann hat man u.U. an einer Stelle in seiner Anwendung kilometerweise ctor Aufrufe. Davon aber nicht abschrecken lassen.
Zu 4) Datenhaltungsobjekte haben eigentlich nix im Container zu suchen, nur die Factory dafür, weil die ja in die entsprechenden Klassen injiziert werden muss, um dann dort Objekte erstellen zu können. Aber es ist auch nichts dagegen einzuwenden, Datenhaltungsobjekte an den Stellen zu erzeugen, wo man sie braucht. Hier gilt der Unterschied zwischen
"newable" und "injectable".
zu 5) natürlich, allerdings wird es mit dem Spring4D Container etwas schwer sofern du Plugins auch wieder entladen willst, denn es ist nicht vorgesehen, Registrierungen während eines Programmdurchlaufes wieder zu entfernen.
zu 6) du kannst es zumindest nicht so leicht inspecten wie eine Objekt Instanz aber ich muss eher selten von außen die Eigenschaften eines Interfaces untersuchen. Außerdem muss ich ganz ehrlich dazu sagen, sobald du mehr bestimmte Prinzipien und Herangehensweisen nutzt, vermindert sich das wirkliche Debuggen (im Sinne von ich steppe durch den Code) und somit auch das inspecten diverser Eigenschaften.
Unit tests helfen dabei sehr, da du da immer nur eine Klasse im Fokus hast.
P.S. Hier noch ein relativ
umfassender Artikel zum Thema DI.