IoC + DI: come si fa con i costruttori?

Ciao a tutti,

ho sentito da qualche parte[*] che se una classe A dipende da una
interfaccia IFoo in maniera "mandatory" è bene esplicitare la dipendenza
come:

class A {
public A(IFoo foo) { ... }
}

Ora, cosa succede quando nella mia applicazione ho due servizi
IGadgetManager e IWidgetManager che dipendono in maniera mandatory l'uno
dall'altro (eventualmente in maniera ciclica)?

Grazie in anticipo e buon finesettimana, :-)
Giulio

[*] = ultimo workshop di dotnet marche. :-p
--

Ciao Giulio,

You wrote on 05/02/2010 :
> ho sentito da qualche parte[*] che se una classe A dipende da una
> interfaccia IFoo in maniera "mandatory" è bene esplicitare la dipendenza
> come:
>
> class A {
> public A(IFoo foo) { ... }
> }
>
> Ora, cosa succede quando nella mia applicazione ho due servizi
> IGadgetManager e IWidgetManager che dipendono in maniera mandatory l'uno
> dall'altro (eventualmente in maniera ciclica)?

io prima mi fermerei a pensare se quella dipendenza sia effettivamente
giusta, perch� a priori un riferimento circolare mi puzza, poi ci sono
casiin cui ha senso sia chiaro. Una possibilit� � quella di mettere in
mezzo un terzo attore che faccia da "provider" per i manager e far
dipendere i componenti da quello.

> Grazie in anticipo e buon finesettimana, :-)

a posteriori altrettanto :-)

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> io prima mi fermerei a pensare se quella dipendenza sia effettivamente
> giusta, perché a priori un riferimento circolare mi puzza,

Ok, hai perfettamente ragione.
Eliminiamo il caso di un riferimento circolare.
Abbiamo che IFoo dipende da IBar e la dipendenza è mandatory. Avendo a
che fare *solamente* con le interfacce, come faccio a esplicitare il
carattere obbligatorio della dipendenza?

Ciao e buona settimana,
Giulio
--

Ciao Giulio,

You wrote on 08/02/2010 :
> Abbiamo che IFoo dipende da IBar e la dipendenza è mandatory. Avendo a
> che fare *solamente* con le interfacce, come faccio a esplicitare il
> carattere obbligatorio della dipendenza?

nel costruttore e poi lascio che il tool per IoC faccia il lavoro
sporco, in fase di registrazione dei componenti, ad esempio in Castle,
indico che a fronte di una richiesta per IBar deve ritornare un'istanza
di BarObj

> Ciao e buona settimana,
> Giulio
> --

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> nel costruttore

Ok... ma dato che le interfacce non hanno costruttore, deduco che la
dipendenza vada esplicitata *fuori* dal codice dell'interfaccia stessa...

> e poi lascio che il tool per IoC faccia il lavoro
> sporco, in fase di registrazione dei componenti, ad esempio in Castle,
> indico che a fronte di una richiesta per IBar deve ritornare un'istanza
> di BarObj

Si, a questo punto devo iniziare a darmi uno sguardo a qualche
contenitore IoC "serio". Per ora ho iniziato con Unity... vediamo un po'
che succede... :-p

Ciao,
Giulio
--

Ciao petrux,

You wrote on 08/02/2010 :
> Ok... ma dato che le interfacce non hanno costruttore, deduco che la
> dipendenza vada esplicitata *fuori* dal codice dell'interfaccia stessa...

esattamente, nel costruttore della classe che implementa IFoo ad
esempio epliciterai la dipendenza da IBar

> Si, a questo punto devo iniziare a darmi uno sguardo a qualche
> contenitore IoC "serio". Per ora ho iniziato con Unity... vediamo un po'
> che succede... :-p

mi sembrava di aver letto "serio"... :-P

> Ciao,
> Giulio
> --

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> esattamente, nel costruttore della classe che implementa IFoo ad
> esempio epliciterai la dipendenza da IBar

Uhm... ok. Al solito, presuppongo che sia il container a leggere la
signature nel costruttore e iniettare le dipendenze, right?

> > Si, a questo punto devo iniziare a darmi uno sguardo a qualche
> > contenitore IoC "serio". Per ora ho iniziato con Unity... vediamo un po'
> > che succede... :-p
>
> mi sembrava di aver letto "serio"... :-P

Ti prego, non frantumare le mie già flebili certezze sull'argomento.
Almeno spiegami perché dovrei usarne un'altro (i.e. Castle Windsor o
Spiring.NET). :-)ù

Ciao,
Giulio
--

Ciao petrux,

You wrote on 09/02/2010 :
> Uhm... ok. Al solito, presuppongo che sia il container a leggere la
> signature nel costruttore e iniettare le dipendenze, right?

si esatto. Nella cnfigurazione del container fai una cosa del tipo
(l'esempio � con Castle ma Unity fa le cose allo stesso modo):

var container = new WindsorContainer();
container.Register( Component.For().ImplementedBy() );
container.Register( Component.For().ImplementedBy() );

supponendo che Bar sia definita:

class Bar : IBar
{
public Bar( IFoo foo )
{ ... }
}

quando farai una cosa del tipo:

var bar = container.Resolve();

Il container fa tutto il giochetto e ti da anche IFoo :-)

> Ti prego, non frantumare le mie già flebili certezze sull'argomento.
> Almeno spiegami perché dovrei usarne un'altro (i.e. Castle Windsor o
> Spiring.NET). :-)ù

sono decisamente pi� maturi e hanno un supporto per l'estendibilit� da
far invidia a qualsiasi cosa... :-) Unity � ancora molto acerbo in
questo senso e per alcune cose Microsoft ci ha proprio messo del suo
per rendere un po' pi� complessa la vita al dev ;-)

Sto usando Unity per una cosa su Silverlight e faccio un po' fatica a
fare cose che con Castle sarebbero mostruosamente banali, probabilmente
� solo questione di abitudine.

> Ciao,
> Giulio
> --

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> sono decisamente pi� maturi e hanno un supporto per l'estendibilit� da
> far invidia a qualsiasi cosa... :-) Unity � ancora molto acerbo in
> questo senso e per alcune cose Microsoft ci ha proprio messo del suo
> per rendere un po' pi� complessa la vita al dev ;-)

Uhm... va be', diciamo che avrò il mio assembly di boostrap che dipende
dal container e qualora decidessimo di accattare Castle invece di
Unity... ;-)

Ciao,
Giulio
--