3 pagine in totale: <<Indietro 1 2 [3]
Anche se in questo articolo non ci si sofferma sul modo con cui l'Enterprise Library utilizza l'Object Builder, in ogni caso occorre sottolineare quanto questa architettura sia altamente configurabile. Chi volesse cimentarsi nell'utilizzo del costruttore d'oggetti in maniera personalizzata, può inserire le proprie "strategie" nelle fasi di creazione dell'oggetto, che specificamente sono: PreCreazione, Creazione, Inizializzazione e PostInizializzazione. Ulteriori informazioni sono disponibili nell'ambito della documentazione dell'EL.
Un sistema come quello descritto, basato su polimorfismo, generics, attributi e reflection, dovrebbe pagare un costo elevatissimo in termini di performance. Eppure, grazie ad un accorto utilizzo della cache per gli oggetti creati tramite reflection, la performance dei blocchi in genere non risulta degradata.
Migrare da v 1.1 a v 2.0?
A parte la mancanza del blocco di configurazione e di ciò che è stato rimosso dal blocco Security, bisogna anche notare che le API (ovvero il modo in cui i metodi vengono invocati) non sono assolutamente identiche. Questo significa che una migrazione dalla versione 1.1 alla 2.0 richiede alcuni cambiamenti. In ogni caso, chi ha già lavorato con EL 1.x si troverà a proprio agio anche con la versione 2.0, perché le API, sebbene non identiche, sono ancora molto simili.
Ad ogni modo, una migrazione dalla versione precedente a quella attuale potrebbe rivelarsi un'operazione non del tutto banale. Nonostante i cambiamenti maggiori siano stati fatti nell'ambito delle parti interne e non esposte della libreria, ci sono ancora abbastanza differenze da rendere una migrazione tout-court impraticabile. Si considerino, ad esempio, i dati di configurazione dei blocchi: nella versione precedente le informazioni relative alla configurazione erano inserite in un file diverso rispetto a quello di configurazione dell'applicazione. In questa release, tutto converge, per impostazione predefinita, all'interno di un solo file, quello di configurazione dell'applicazione.
Informazioni specifiche ad ogni tipo di blocco sono state inserite all'interno della documentazione che è installata assieme all'Enterprise Library.
Una benevola convivenza
Fortunatamente, la migrazione da una versione precedente a quella attuale non deve essere a tutti i costi attuata. Anzi, sembra di capire, leggendo tra le righe delle pagine di MSDN dedicate all'argomento e i commenti dei blogger, che una migrazione non sia in fondo la pratica più raccomandabile.
Così com'è possibile infatti mantenere sullo stesso computer Visual Studio 2003 assieme alla versione 2005, è anche possibile avere due versioni diverse dell'Enterprise Library, che possono convivere l'una accanto all'altra senza particolari problemi.
Infine, se proprio è necessario migrare, un approccio consigliato è quello di spostare un assembly alla volta, in modo da poter gestire il cambiamento senza troppa complessità e senza i soliti costi e rischi caratteristici di una migrazione.
L'ideale probabilmente sarebbe quello di utilizzare la nuova EL solo con le nuove applicazioni, ma non è sempre detto che questa sia la migliore opzione per ogni situazione.
L'importante è sempre valutare l'impatto del cambiamento e preferire la soluzione più semplice e più facile da gestire. Bisogna ricordare che, in fondo, alla base della scelta dell'utilizzo di ogni tipo di pattern pre-esistente (e qui ci siamo completamente dentro), vi è sempre la ricerca del minor consumo. "Di meno è meglio", disse un certo monaco appassionato di logica di nome Ockham, vissuto sette secoli fa in Inghilterra. E la sua idea è ancora valida. Quindi, se una migrazione non è veramente necessaria, tutto sommato la possiamo evitare.
Conclusioni
Sicuramente esistono diversi programmatori che in passato hanno provato ad utilizzare l'EL, hanno trovato alcune difficoltà e hanno preferito lasciar perdere. Di certo ci sono state e probabilmente ci saranno sempre imperfezioni nell'EL. È un grosso progetto e una sfida importante per coloro che la stanno realizzando. Ad ogni modo non bisogna scoraggiarsi perché i vantaggi che essa promette in termini di riutilizzo e ottimizzazione di codice sono veramente grandi (e reali).
Detto questo, bisogna sempre valutare se è il caso di utilizzare l'Enterprise Library, quali blocchi usare e in quali occasioni. In genere questo dipende dal buon senso e dell'esperienza.
Approfondimenti e download
Ci sarebbe molto da dire sull'Enterprise Library, ma la maggior parte delle informazioni utili si possono trovare sul web, anche se soprattutto in lingua inglese.
Innanzitutto bisogna ricordare che l'Enterprise Library è inserita in una sezione di MSDN che si chiama Microsoft Patterns & Practices, una sezione che costantemente si dedica all'architettura software nell'ottica del riutilizzo di codice e pattern ottimizzati.
È possibile scaricare l'Enterprise Library for .NET Framework 2.0 cliccando qui.
Di particolare interesse è la sezione dedicata ai blogger che discutono di EL, forse la migliore risorsa online per tenersi aggiornati su EL.
Esiste inoltre una sezione chiamata Upcoming Webcasts che anticipa la diffusione di alcuni video, chiamati appunti webcast, relativi all'EL.
La versione precedente dell'Enterprise Library per coloro che ancora non utilizzano Visual Studio 2005 è disponibile qui.
Altre risorse: una pagina sugli Application Block in genere, anche al di fuori della libreria, e un'ottima fonte per conoscere meglio i singoli blocchi. In quest'ultimo riferimento è possibile trovare le spiegazioni dettagliate sui singoli blocchi, diagrammi che ne illustrano l'architettura con efficaci esempi di codice, sia in C# che in VB.NET.
3 pagine in totale: <<Indietro 1 2 [3]
Contenuti dell'articolo
- Pagina 1
- Pagina 2
- Pagina 3
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Utilità
Stampa 
Download 
