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?

RG .NET Reflector

Come vedete, non ho molto tempo per bloggare.
Oggi, però, un'eccezione devo pur concedermela.
Sono infatti venuto a conoscenza che .NET Reflector non è più uno strumento gratuito.
L'annuncio lo trovate quì.

Onestamente, ci sono rimasto male e la natura del mio malessere non deriva certo da quei 35 dollari.
Io  a colpi di reflector ci sono cresciuto, e ammetto di dover molto a questo strumento.
Proprio per questo motivo mi chiedo se non vi fossero effettivamente altre strade da percorrere.
Insomma, a mio avviso non è stata una mossa molto trasparente.

Ovviamente, è subito pronta l'alternativa (ILSpy).
«March»
SunMonTueWedThuFriSat
272812345
6789101112
13141516171819
20212223242526
272829303112
3456789