Es un hecho de la vida que las organizaciones tienen diferentes aplicaciones que usan diferentes versiones de las mismas clases porque se desarrollaron en diferentes momentos y no pueden mantenerse al día. También es un hecho de la vida que estas aplicaciones a menudo necesitan compartir datos entre sí.
Puede hacerlo a través de la base de datos. Sin embargo, eso es lento y no escalable. Lo que realmente quieres es compartir objetos a través de un caché distribuida que es rápido y escalable. Pero, compartir objetos en tiempo de ejecución plantea inmediatamente el problema de la compatibilidad de versiones.
Una forma de hacerlo es a través de XML en el que puede transformar una versión de un objeto en otra. Pero es extremadamente lento. Otra forma es implementar su propia transformación personalizada que toma una versión de objeto y la transforma en otra versión. Pero, tienes que mantener esto, lo cual es mucho esfuerzo para ti.
¿No sería bueno si el caché distribuido de alguna manera se encargara de la compatibilidad de versiones por usted? Bien, NCache hace exactamente eso. NCache le proporciona una transformación de objetos de nivel binario entre diferentes versiones. Puede mapear diferentes versiones a través de un archivo de configuración XML y NCache entiende cómo transformar de una versión a otra.
Además, desde NCache almacena todas estas versiones diferentes en un formato binario (en lugar de XML), el tamaño de los datos se mantiene muy compacto y pequeño y, por lo tanto, rápido. En un entorno de alto tráfico, el tamaño del objeto se suma a un gran consumo de ancho de banda adicional, que tiene su propio costo asociado.
Aquí hay un ejemplo de NCache config.ncconf con asignación de versión de clase:
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> |
¿Cómo NCache ¿hazlo?
En el archivo config.nconf que ve arriba, notará que la clase Empleado tiene un conjunto de atributos definidos primero. Estos son atributos independientes de la versión y aparecen en todas las versiones. Este es en realidad un superconjunto de todos los atributos que aparecen en diferentes versiones. Debajo de eso, especifica los atributos específicos de la versión y los asigna a los atributos independientes de la versión anteriores.
Digamos que guardó la versión 1.0.0.0 de Employee, que tenía un subconjunto de la versión 2.0.0.0 de Employee. Ahora, cuando otra aplicación intenta obtener el mismo empleado, pero quiere verlo como la versión 2.0.0.0, NCache sabe qué atributos de la versión 2.0.0.0 rellenar con datos y cuáles dejar en blanco.
En segundo lugar, en la configuración de muestra anterior, notará que la versión 2.0.0.0 de Employee no tiene el campo Dirección, aunque la versión 1.0.0.0 sí lo tiene. Entonces, en este caso, cuando NCache intenta leer Employee 1.0.0.0 almacenado en el caché e intenta transformarlo a Employee versión 2.0.0.0, sabe que no debe copiar el campo Dirección porque no está allí en esta versión más nueva.
Hay muchos otros escenarios que NCache maneja a la perfección para usted. Lea la documentación del producto en línea para obtener más detalles al respecto.
Finalmente, la mejor parte de todo esto es que no tiene que escribir ningún código de serialización ni realizar ningún cambio en el código de su aplicación para usar este NCache . NCache ha implementado un mecanismo de generación de código en tiempo de ejecución, que genera código de serialización y deserialización en memoria de sus clases en tiempo de ejecución, y utiliza el formulario compilado que es muy rápido.
En resumen, usando NCache ahora puede compartir diferentes versiones de objetos entre sus aplicaciones sin siquiera modificar el código de su aplicación.