3 pagine in totale: <<Indietro 1 2 [3]
Architettura dell'Add-in model e gestione delle versioni
Quando un'applicazione è stata rilasciata (e spesso prima ancora), gli autori sanno già quali miglioramenti vogliono introdurre nella versione successiva. Il problema per chi scrive applicazioni estensibili è apportare qualunque cambiamento senza influire sulla funzionalità delle estensioni esistenti che girano sull'attuale versione del prodotto. L'approccio migliore è definire nuove interfacce che ereditano da quelle delle versione precedente e fare si che il nuovo host e i nuovi add-in tentino di fare un cast per verificare se gli oggetti che sono passati ereditano la nuova interfaccia o la vecchia. Il problema di questo approccio è che costringe sia l'host sia gli add-in di avere completa visibilità su tutte le versioni delle interfacce, ed entrambi devono farsi carico della complessità addizionale di gestire tutte le versioni dell'interfaccia.
Nel modello che si introduce in .NET Framework 3.5, viene definita un'architettura che permette all'host e agli add-in di riferirsi ad una view dell'object model, e fornisce ai developer degli host un modo per aggiungere la logica di conversione da una versione all'altra in un assembly a parte (detto adapter).
Architettura della pipeline
In figura 2 potete vedere una visualizzazione dell'architettura progettata per semplificare la comunicazione versionabile tra host e add-in. L'obiettivo è di fornire una view stabile dell'object model sia agli host sia agli add-in, con livelli di astrazione che isolano ciò che viene veramente passato attraverso il confine tra i componenti, come è stato convertito da una versione all'altra e perfino come è stato ricevuto dall'altra parte.
Ogni elemento in figura rappresenta un assembly che contiene molti tipi diversi. Tipicamente, per ogni oggetto scambiato tra un add-in e un host, esiste un tipo in ogni view, adapter e contratto. L'host e l'add-in sono le entità che implementano la vera funzionalità del sistema, mentre le altre entità rappresentano l'object model, passano i dati attraverso i confini del componente ed eseguono le necessarie traduzioni.
Guardando Figura 2, molte proprietà di questa architettura risultano evidenti. Innanzitutto, il fatto che l'host e l'add-in dipendono soltanto dalle view e che le view non hanno altre dipendenze da alcun altro componente della pipeline. Questo fornisce la barriera astratta che permette all'host e all'add-in di ignorare completamente come l'altro e la comunicazione con l'altro sono implementati.
Un altro aspetto importante di questa architettura è come il modello sia completamente simmetrico rispetto al confine tra i componenti. Questo implica che non c'è alcuna differenza dal punto di vista architetturale tra come gli host e gli add-in comunicano tra loro. Nel modello, l'unica differenza tra un host e un add-in è che l'host è l'entità che attiva l'add-in. Una volta che l'attivazione è avvenuta, host e add-in sono trattai allo stesso modo nel sistema.
Isolamento e reliability
Uno dei problemi più seri che un host di add-in deve affrontare è come gestire il malfunzionamento di un add-in. Usando COM add-ins, questo vuole dire di solito che l'host va in crash.
Il modello incluso in .NET 3.5 consente ad un host di isolare add-ins in un application domain separato o perfino in un processo a parte con una riga di codice.
Questo codice trova e attiva tutti gli add-in di tipo AddInType ciascuno in un suo application domain. In questo caso l'host può decidere di fare un unload di un add-in indipendentemente dagli altri.
AddInStore.Update(addinPath);
IList tokens =
AddInStore.FindAddIns(typeof(AddInType), addinPath);
foreach (AddInToken token in tokens)
{
token.Activate(AddInSecurityLevel.Internet);
}
Se ci si vuole garantire da malfunzionamenti critici di un add-in (stack overflow, out-of-memory, etc) si può scegliere di isolare ogni add-in in un processo a parte aggiungendo un parametro alla chiamata di Activate:
AddInStore.Update(addinPath);
IList tokens =
AddInStore.FindAddIns(typeof(AddInType), addinPath);
foreach (AddInToken token in tokens)
{
token.Activate(new AddInProcess(),
AddInSecurityLevel.FullTrust);
}
Si possono anche avere soluzioni ibride, dove si crea un processo esterno e si isolano in esso diversi add-in, ciascuno nel suo application domain:
AddInStore.Update(addinPath);
IList tokens =
AddInStore.FindAddIns(typeof(AddInType), addinPath);
AddInProcess sharedProcess = new AddInProcess();
foreach (AddInToken token in tokens)
{
token.Activate(sharedProcess,
AddInSecurityLevel.FullTrust);
}
Conclusioni
Con questi piccoli approfondimenti su quanto di nuovo potete trovare nel CLR e nella BCL di NET Framework 3.5 "Orcas", spero di avervi incuriosito a sufficienza per spingervi a provare il tutto di persona.
Ringrazio Daniele e tutto lo staff di ASPItalia.com e WinFXItalia.com per avermi ospitato nelle loro pagine e Claudio Caldato, PM per performance e GC nel CLR, per il suo aiuto. Arrivederci.
Lo speciale completo
- Le novità in .NET Framework 3.5 di Alessandro Catorcini
- Introduzione a C# 3.0 di Riccardo Golia
- Introduzione a Visual Basic 9 di Cristian Civera
- Le novità di ASP.NET Orcas beta 1 di Daniele Bochicchio
- Introduzione a LINQ di Stefano Mostarda
3 pagine in totale: <<Indietro 1 2 [3]
Contenuti dell'articolo
- Introduzione a .NET Micro Framework
- Gestire transazioni miste con NTFS in Windows Server 2008
- Windows Presentation Foundation 3.5: 3D interattivo e le altre novità del framework
- Le novità di Communication e Workflow Foundation e la loro cooperazione nel .NET Framework 3.5
- .NET Framework 3.5 e Visual Studio 2008: cosa c'è di nuovo
- Gestione delle eccezioni in Windows Communication Foundation
- Sviluppare workflow sequenziali con WF
- WPF: dal DataBinding ai Template - Terza parte
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Contenuti
Stampa 
Download 
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!