Desgin: DependencyInjection ja oder nein!?



  • Hallo Leute,

    ich möchte Abhängikeiten definiert in einem Interface (IFoo) von Klassen via Reflection zuweißen, da ich diese nich im Konstruktor von IFoo-Implementationen machen will.

    1. Kann ich sowa auch anders /besser lösen, oder ist das ein typischer fall von DP?

    2. Wäre statt eine Interface (IFoo) eine Abstracte Klasse (mit DP feld) besser?

    Danke und grüße;)

    class DependecyObject
    	{
    		public void DoSomething()
    		{
    			...
    		}
    	}
    
    	class Foo :IFoo
    	{
    		public Foo()
    		{
    			...
    		}
    
    		#region Implementation of IFoo
    
    		public DependecyObject DpObject { get; private set; }
    
    		public void Init()
    		{
    			DpObject.DoSomething();
    		}
    
    		#endregion
    	}
    
    	interface IFoo
    	{
    		//Abhängigkeit
    		DependecyObject DpObject { get; }
    
    		//Object Initialisieren
    		void Init();
    	}
    
    	class Bar
    	{
    		public Bar(DependecyObject dp, IFoo foo)
    		{
    			//Abhängigkeit setzen
    			var prop = typeof(IFoo).GetProperty("DpObject");
    			prop.SetValue(foo, dp);
    
    			//Initialisieren
    			foo.Init();
    		}
    	}
    


  • NullBockException schrieb:

    ich möchte Abhängikeiten definiert in einem Interface (IFoo) von Klassen via Reflection zuweißen, da ich diese nich im Konstruktor von IFoo-Implementationen machen will.

    Warum nicht? Für sowas ist der Konstruktor doch da. Init-Methoden sind i.A. doof, öffentliche ganz besonders.



  • Weil die Implementieren- Klassen von IFoo tiefe ableitung hierachie haben können, und ich so die ganzen abhänigen immer durchschleifen muss hmm...

    naja könne auich nen container verwenden.. der alles diese abhängigkeiten hat...



  • NullBockException schrieb:

    Weil die Implementieren- Klassen von IFoo tiefe ableitung hierachie haben können, und ich so die ganzen abhänigen immer durchschleifen muss hmm...

    Der Text ist eine Zumutung. Kannst du dir mal ein bißchen Mühe geben, wenn du eine Replik in die Tastatur hackst?

    Jedenfalls glaube ich, daß du gut daran tust, die Abhängigkeiten im Konstruktor anzugeben. Wenn das Mühe macht, kannst du ja mal lesbar erklären warum, vielleicht kann man dann das eigentliche Problem erforschen und beheben.

    Und die Sache mit dem "container [...] der alles diese abhängigkeiten hat" ist bekannt unter dem Namen service locator anti-pattern.



  • audacia schrieb:

    Und die Sache mit dem "container [...] der alles diese abhängigkeiten hat" ist bekannt unter dem Namen service locator anti-pattern.

    Ich halte den "Service Locator" zwar auch für ein Anti-Pattern, doch gibt es zwei nicht kleine Fraktionen mit einer hier gegensätzlichen Meinungen (Die einen zählen es zu den Pattern, die anderen zu den Anti-Pattern).

    NullBockException schrieb:

    Weil die Implementieren- Klassen von IFoo tiefe ableitung hierachie haben können, und ich so die ganzen abhänigen immer durchschleifen muss hmm...

    1. Tiefe Vererbungshierarchien sollte man besser vermeiden.
    2. Für Dependency Injection wird in der Regel der Konstruktor verwendet (Property-Injection ist zwar von dem ein oder anderen DI-Container vorgesehen aber häufiger ist Constructor-Injection)



  • Vielleicht wäre das Buch "Dependency Injection in .NET" etwas für dich (Auch wenn sich in den letzten Jahren das ein oder andere geändert haben mag).



  • asc schrieb:

    audacia schrieb:

    Und die Sache mit dem "container [...] der alles diese abhängigkeiten hat" ist bekannt unter dem Namen service locator anti-pattern.

    Ich halte den "Service Locator" zwar auch für ein Anti-Pattern, doch gibt es zwei nicht kleine Fraktionen mit einer hier gegensätzlichen Meinungen (Die einen zählen es zu den Pattern, die anderen zu den Anti-Pattern).

    Das ist, glaube ich, nur ein Mißverständnis. Ein service locator selbst ist noch kein Antipattern. Die Verwendung, wie der OP sie mutmaßlich vorsieht (alle Abhängigkeiten durchreichen ist zu unpraktisch, sollen die Komponenten sie doch selber nachschlagen), ist das Antipattern. Dem stimmen meines Wissens auch die Leute zu, die sich gegen den Begriff "Antipattern" wenden. Z.B. der hier (unter den ersten Google-Treffern):
    http://blog.gauffin.org/2012/09/service-locator-is-not-an-anti-pattern/

    [bad example]
    I agree 100%. The service locator do not work very well in that case. I strongly discourage you from abusing the locator in that way. Dependencies/information which is required should always be injected through the constructor.


Anmelden zum Antworten