Newsgroup: it.comp.dotnet
Titolo: Unity: risoluzione "parametrica".

Ciao a tutti,
Sto avendo """qualche""" problema nell'utilizzo di Unity. Più 
precisamente mi trovo in una situazione del genere:
interface IFoo { ... }
class XFoo : IFoo { ... }
class YFoo : IFoo { public YFoo(string s) { ... } }
vorrei che richiamando:
IUnityContainer uc = ...;
uc.Resolve<IFoo>();
il container risolva una istanza di IFoo (eventualmente registrata come 
singleton, ma questo è un altro discorso).
Inoltre vorrei poter fare una cosa tipo:
uc.Resolve<IFoo>("ciao");
e ottenere una istanza di YFoo con la stringa passata al metodo 
.Resolve(...) passata nel costruttore.
Qualche aiuto?
Ciao e grazie,
Giulio
--

 Qualche aiuto?
vado molto a memoria ma credo non sia supportato...
ripeti insieme a me: Castle Windsor, Ninject, AutoFac, Spring... non 
Unity :-)
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it

 .m
Autofac +1 :)
-- 
Raffaele Rialdi  
http://www.iamraf.net
Weblog: 
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - 
http://www.ugidotnet.org/

 ripeti insieme a me: Castle Windsor, Ninject, AutoFac, Spring
Dal punto di vista delle performances avevo letto tempo fa che Ninject 
era sconsigliato: è ancora vero oppure no?

 Unity :-)
Va be'... mi sa che Unity farà la stessa fine di EntityFramework: 
dimenticato e abbandonato. :-) Eppure a me la cosa sembra molto 
strana... che voi sappiate la MS sta spingendo più su MEF piuttosto che 
su un "banale" container di IoC come Unity?


Ciao dedalus,

mai avuto il piacere, io vivo felice con Castle Windsor.


 mai avuto il piacere, io vivo felice con Castle Windsor.
Uhm... mi sa che tra un po'... :-)
Ciao,
Giulio
-- 

 container di IoC come Unity?
Uhm, sono bestie diverse.
Con IoC hai una pluggabilità di cose "prevedibili" cioè componenti che 
tu stesso andrai a disegnare ma di cui vuoi evitare dipenze statiche 
per vari motivi tra cui il versioning.
Con MEF invece vuoi dare una pluggabilità a terze parti e quindi una 
dinamicità a runtime scoprendo a runtime se c'è un plugin che può 
svolgere un determinato lavoro.
Detto ciò ci possono ovviamente essere sovrapposizioni o casi nei quali 
puoi utilizzare indifferentemente entrambi, ma resta il fatto che sono, 
al momento, cose differenti.


 container di IoC come Unity?
Unity e MEF sono due cose molto diverse, ho la sensazione che Unity, 
pura sensazione mia, non sia molto coccolato.


 puoi utilizzare indifferentemente entrambi
Era proprio a questo che mi riferivo. A livello teorico sarebbe 
plausibile "spingere" in questa direzione, no?
Ciao,
Giulio
-- 

 "spingere" in questa direzione, no?
Ciao Giulio,
ha senso solo se modificano MEF in modo da coprire entrambe le 
casistiche.
Adesso vado con un'esternazione controcorrente :)
La rottura dei legami statici (compile time) è bella dal punto di vista 
architetturale ma è un delirio quando leggi i sorgenti.
I tool come 
vs.net
 (F12) e reflector non ti consentono più di capire 
chi chiama cosa e devi fare ricerche molto più faticose e lunghe.
Questo significa che quando nuovi membri di un team studiano 
l'applicazione, ci metteranno molto più tempo.
D'altra parte è giusto prevedere dei punti di pluggabilità altrimenti 
la mega-applicazione-monolitica diventa un delirio per un altro verso.
Il punto chiave secondo me è di trovare il giusto equilibrio.
In questo senso IoC è molto più a rischio di abuso rispetto a MEF.
Se usi MEF è perché evidentemente hai un requirement forte di 
pluggabilità (terze parti che devono estendere l'app).
IoC invece *rischia* di essere ficcato dentro per forza, per una sorta 
di maniacalità architetturale.
Ferma, non sto dicendo che non serva o che sia sempre così. Ho detto 
*rischia*.
Quindi a mio avviso IoC va usato con molta più cautela e solo dove 
veramente ha senso farlo e nei punti dell'applicazione dove dal disegno 
il disaccoppiamento è palese anche per chi non conosce ancora bene 
l'applicazione.


 l'applicazione.
Guarda, su questo molto fa anche il livello di "alfabetizzazione" del 
team. Ti spiego con un esempio. Subito dopo la laurea, il mio primo 
lavoro da sviluppatore è stato in una start-up. Pochissimo know-how 
"pregresso", alcuni elementi di un team (diffuso su tutto il globo) 
davvero "caotici". Siamo passati da stringhe di connessione hard-coded 
nell'html, o tutta l'applicazione cablata nel main(string[] args) { ... 
} a progetti (non lo dico per vanto, se seguite le mie rutilanti 
esternazioni qui o sul forum guisa sapete bene che sono uno gnucco e lo 
manifesto senza un briciolo di vergogna :-p) ben strutturati.
Ora, noi developers della prima leva storciamo il naso se vediamo un 
approccio "monolitico", ma per un giovane stagista di 21 anni l'avere:
public class Foo
{
	public Foo(IBar bar) { ... }
}
può essere una assurdità. Il problema (e potremmo dire che è IL problema 
dell'umanità in quanto tale) è la conoscenza. :-) Certo è pure vero che 
definire bene i punti di pluggabilità è una buona cosa... :-p
Ciao,
Giulio
-- 

 Guarda, su questo molto fa anche il livello di "alfabetizzazione" del team. 
[...]
Totalmente daccordo.
