EL5: una dipendenza inutile

Ok, visto che sono quì, non vedo perchè dovrei privarmi del piacere di bloggare ancora per un pò.
A dire il vero, mi piacerebbe scrivere qualcosa su MEF, che ho cominciato a scoprire da poco e del quale mi sonosubito innamorato. In realtà, per motivi di tempo, mi voglio limitare a segnalare quella che, a mio avviso, è una piccola anomalia che ho riscontrato in Enterprise Library.
Sto seguendo un progetto piuttosto interessante e diciamo pure che ho accolto da subito con entusiasmo la sfida che mi è stata proposta.
Il problema è che mi trovo a che fare con dei database legacy della peggior specie. Anzi, devo chiaramente dire che è la peggior infrastruttura con la quale abbia mai avuto a che fare.
Sono innegabilmente un fan di NHibernate e la mia prima idea è stata quella di avvalermi di tale strumento per cercare di rendermi la vita un pò più semplice.
Niente da fare. E' probabile che ciò sia in qualche modo frutto della mia scarsa esperienza con il software legacy, ma applicare anche una primitiva forma di O/R Mapping a ciò che ho fra le mani è, secondo la mia modestissima opinione, una "Mission Impossible" per chiunque.
Mi sono quindi chiesto se non fosse il caso di utilizzare il Data Access Block di EL, giusto per alleviare un pò il dolore. E devo dire che l'impresa è riuscita egregiamente.
Mentre eseguivo i test, però, mi sono trovato a che fare con un'eccezione all'interno della quale mi veniva segnalato che, sostanzialmente, il componente in oggetto necessitava dell'assembly "Microsoft.Practices.Unity".
E perchè mai dovrei aggiungere un riferimento ad un componente come "Unity" se, ad esempio, risolvo le mie dipendenze con Castle Windsor?
Mi è sembrato tutto molto illogico.
L'analisi dello stack chiamava chiaramente in causa il costruttore di Microsoft.Practices.EnterpriseLibrary.Data.RefCountingDataReader.
Ecco cosa viene fuori dai sorgenti:

public RefCountingDataReader(DatabaseConnectionWrapper connection, IDataReader innerReader) : base(innerReader)
{
Guard.ArgumentNotNull(connection, "connection");
Guard.ArgumentNotNull(innerReader, "innerReader");
this.connectionWrapper = connection;
this.connectionWrapper.AddRef();
}


Ebbene, Guard è una classe (tra l'altro, pubblica) definita all'interno dell'assembly "Microsoft.Practices.Unity".
Perchè è stata compiuta questa scelta?
Non potevano, ad esempio, definirla all'interno di un assembly come, non so, "Microsoft.Practices.EnterpriseLibrary.Common"?
Insomma, stiamo parlando di una classe statica buttata nel mezzo senza il benchè minimo criterio.
C'è forse qualcuno che conviene con il sottoscritto?

posted @ Tuesday, March 22, 2011 11:10 PM

Print

Comments on this entry:

# re: EL5: una dipendenza inutile

Left by raffaeu at 3/23/2011 12:21 AM
Gravatar
Purtroppo e' stata una scelta architetturale, sbagliata. L' anno scorso sono stato in MS per P&P al symposium ed ho proprio fatto la stessa domanda ai creatori di EL5. L' inquinamento con Unity e' ovunque proprio perche' loro NON vogliono che tu usi un motore di DI diverso da unity. Il perche' non lo so ma se vuoi puoi ricompilare EL5 con un IoC diverso. In bocca al lupo!

# re: EL5: una dipendenza inutile

Left by naighes at 3/23/2011 5:01 PM
Gravatar
> se vuoi puoi
> ricompilare EL5 con un IoC diverso.
Per l'amor del cielo!
Aggiungo la dipendenza! ;-)
Comments have been closed on this topic.
«December»
SunMonTueWedThuFriSat
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234