Jeg bruger en del tid på at overveje hvordan og i hvilket omfang jeg skal bruge et IoC framework. Jeg skrev en post om mine overvejelser, og den afstedkom nogle tilbagemeldinger med links til mere info, og gode råd om hvilke frameworks der skal foretrækkes. Det jeg søger er bare, et førstehånds indtryk, fra brugere der arbejder med et af disse frameworks til dagligt.

Jeg har søgt videre, og faldt over en post af Ayende Rahien, hvor han tager netop dette emne op i en serie poster. Han starter med at konstruerer en container på 15 betydende linjer. Jeg blev straks bidt lidt af ideen, og besluttede at bruge hans eksempel som udgangspunkt for min udforskning af behovet. Jeg mener: Med så minimal en implementering, må man da kunne danne sig et overblik. Jeg vil faktisk tage den lidt længere, og starte med en container på 10 linjer:

public class Container{
    	private static readonly Dictionary register = new Dictionary(); 
	
	public void 	Register(Func creator){ 
		register.Add(typeof(T), creator); 
	} 
	
	public T Create(){ 
		return (T)register[typeof(T)](); 
	} 
} 

Andet skal der ikke til, for at lave dependecy injection. Her er lidt klientkode:

//Registrering: 
ioc.Register(() =>; new EMailer()); 

// Injection: 
ioc.Create().Send("jj@icoder.dk", "Hej fra Ioc containeren");

På denne måde, er det muligt at registrere sine implementeringer, og instantierer dem. Jeg har faktisk kørt med denne container i et par uger, og den er langt hen ad vejen nok til mit behov. Jeg har i hvert tilfælde fået afkoblet mine afhængigheder, og gjort testning meget lettere. Hvad er det så man mangler, når man kører med så begrænset et objekt?

• For det første, så kan jeg se et mønster i at jeg opretter konkrete implementeringer af interfaces, og efterfølgende registrerer dem, i containeren, i min application-start. Et framework som Windsor laver denne registrering automatisk, når man blot laver en konstruktør med de nødvendige afhængigheder som parametre – det må være en stor hjælp, hvis man arbejder med systemer, med mange klasser og delegates.
• For det andet, så har jeg et behov for at kunne angive en eller anden form for livstid på objekterne. Skal objektet være en singleton, en pr. session eller pr request variabel, eller kan man nøjes med at returnere en ny instans hver gang, som her.
• For det tredje, kunne jeg måske tænke mig en mulighed for en eller anden form for kontekst angivelse, hvor man f.eks. kunne styre transaktioner, men jeg er ikke helt sikker på den del endnu, eller om det i det hele taget hører hjemme i et IoC framework.

Det er hvad mine behov har vist sig at være efter et par uger med 10 linjers container kode.

Code on…

Andet skal der ikke til, for at lave dependecy injection. Her er lidt klientkode:

//Registrering: 
ioc.Register(() => new EMailer()); 

// Injection: 
ioc.Create().Send("jj@icoder.dk", "Hej fra Ioc containeren");

På denne måde, er det muligt at registrere sine implementeringer, og instantierer dem. Jeg har faktisk kørt med denne container i et par uger, og den er langt hen ad vejen nok til mit behov. Jeg har i hvert tilfælde fået afkoblet mine afhængigheder, og gjort testning meget lettere. Hvad er det så man mangler, når man kører med så begrænset et objekt?

• For det første, så kan jeg se et mønster i at jeg opretter konkrete implementeringer af interfaces, og efterfølgende registrerer dem, i containeren, i min application-start. Et framework som Windsor laver denne registrering automatisk, når man blot laver en konstruktør med de nødvendige afhængigheder som parametre – det må være en stor hjælp, hvis man arbejder med systemer, med mange klasser og delegates.
• For det andet, så har jeg et behov for at kunne angive en eller anden form for livstid på objekterne. Skal objektet være en singleton, en pr. session eller pr request variabel, eller kan man nøjes med at returnere en ny instans hver gang, som her.
• For det tredje, kunne jeg måske tænke mig en mulighed for en eller anden form for kontekst angivelse, hvor man f.eks. kunne styre transaktioner, men jeg er ikke helt sikker på den del endnu, eller om det i det hele taget hører hjemme i et IoC framework.

Det er hvad mine behov har vist sig at være efter et par uger med 10 linjers container kode.

Code on…