È un dato di fatto che le organizzazioni hanno applicazioni diverse che utilizzano versioni diverse delle stesse classi perché sono state sviluppate in momenti diversi e non sono in grado di tenere il passo. È anche un dato di fatto che queste applicazioni spesso hanno bisogno di condividere i dati tra loro.
Puoi farlo attraverso il database. Tuttavia, è lento e non scalabile. Quello che vuoi veramente è condividere oggetti attraverso a cache distribuita che è veloce e scalabile. Tuttavia, la condivisione degli oggetti in fase di esecuzione solleva immediatamente il problema della compatibilità delle versioni.
Un modo per farlo è tramite XML in cui puoi trasformare una versione di un oggetto in un'altra. Ma è estremamente lento. Un altro modo è implementare la propria trasformazione personalizzata che prende una versione dell'oggetto e la trasforma in un'altra versione. Ma devi mantenerlo, il che è un grande sforzo per te.
Non sarebbe bello se la cache distribuita si occupasse in qualche modo della compatibilità delle versioni per te? Bene, NCache fa esattamente questo. NCache fornisce una trasformazione di oggetti a livello binario tra diverse versioni. È possibile mappare diverse versioni tramite un file di configurazione XML e NCache sa come passare da una versione all'altra.
Inoltre, da allora NCache memorizza tutte queste diverse versioni in un formato binario (piuttosto che XML), la dimensione dei dati rimane molto compatta e piccola e quindi veloce. In un ambiente ad alto traffico, la dimensione dell'oggetto si aggiunge a un notevole consumo di larghezza di banda, che ha un suo costo associato.
Ecco un esempio di NCache config.ncconf con mappatura della versione della classe:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
<cache-config name="myInteropCache" inproc="False" config-id="0" last-modified="" type="clustered-cache" auto-start="False"> ... <data-sharing> <type id="1001" handle="Employee" portable="True"> <attribute-list> <attribute name="_Name" type="System.String" order="1"> <attribute name="_Age" type="System.Int32" order="2"> <attribute name="_Address" type="System.String" order="3"> <attribute name="_ID" type="System.String" order="4"> <attribute name="_PostalAddress" type="System.String" order="5"> </attribute></attribute></attribute></attribute></attribute></attribute-list> <class name="DataModel.Employee:1.0.0.0" handle-id="1" assembly="DataModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" type="net"> <attribute name="_Name" type="System.String" order="1"> <attribute name="_Age" type="System.Int32" order="2"> <attribute name="_Address" type="System.String" order="3"> </attribute></attribute></attribute></class> <class name="DataModel.Employee:2.0.0.0" handle-id="2" assembly="DataModel, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null" type="net"> <attribute name="_ID" type="System.String" order="4"> <attribute name="_Name" type="System.String" order="1"> <attribute name="_Age" type="System.Int32" order="2"> <attribute name="_PostalAddress" type="System.String" order="3"> </attribute></attribute></attribute></attribute></class> </type> </data-sharing> ... </cache-config> |
Che aspetto ha e come funziona il NCache fallo?
Nel file config.nconf che vedi sopra, noterai che la classe Employee ha una serie di attributi definiti per primi. Questi sono attributi indipendenti dalla versione e compaiono in tutte le versioni. Questo è in realtà un superset di tutti gli attributi che appaiono in diverse versioni. Di seguito, specifichi gli attributi specifici della versione e li associ agli attributi indipendenti dalla versione sopra.
Supponiamo che tu abbia salvato la versione Employee 1.0.0.0, che aveva un sottoinsieme della versione Employee 2.0.0.0. Ora, quando un'altra applicazione tenta di recuperare lo stesso dipendente, ma vuole vederlo come versione 2.0.0.0, NCache sa quali attributi della versione 2.0.0.0 riempire con i dati e quali lasciare vuoti.
In secondo luogo, nella configurazione di esempio precedente noterai che la versione 2.0.0.0 di Employee non contiene il campo Indirizzo anche se la versione 1.0.0.0 lo ha. Quindi, in questo caso, quando NCache prova a leggere Employee 1.0.0.0 memorizzato nella cache e prova a trasformarlo in Employee versione 2.0.0.0, sa di non copiare il campo Address perché non è presente in questa versione più recente.
Ci sono molti altri scenari che NCache gestisce perfettamente per te. Si prega di leggere la documentazione in linea del prodotto per maggiori dettagli su questo.
Infine, la parte migliore di tutto questo è che non devi scrivere alcun codice di serializzazione o apportare modifiche al codice alla tua applicazione per poterlo utilizzare NCache caratteristica. NCache ha implementato un meccanismo di generazione del codice di runtime, che genera la serializzazione in memoria e il codice di deserializzazione delle tue classi in fase di runtime e utilizza il modulo compilato che è molto veloce.
In sintesi, utilizzando NCache ora puoi condividere diverse versioni di oggetti tra le tue applicazioni senza nemmeno modificare il codice dell'applicazione.