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 @ mercoledì 23 marzo 2011 01:10