Es ist eine Tatsache, dass Unternehmen unterschiedliche Anwendungen haben, die unterschiedliche Versionen derselben Klassen verwenden, weil sie zu unterschiedlichen Zeitpunkten entwickelt wurden und nicht mithalten können. Es ist auch eine Tatsache, dass diese Anwendungen häufig Daten miteinander teilen müssen.
Sie können dies über die Datenbank tun. Das ist jedoch langsam und nicht skalierbar. Was Sie wirklich wollen, ist, Objekte über a zu teilen verteilter Cache das ist schnell und skalierbar. Die gemeinsame Nutzung von Objekten zur Laufzeit wirft jedoch sofort das Problem der Versionskompatibilität auf.
Eine Möglichkeit hierfür ist XML, mit dem Sie eine Version eines Objekts in eine andere umwandeln können. Aber es ist extrem langsam. Eine andere Möglichkeit besteht darin, eine eigene benutzerdefinierte Transformation zu implementieren, die eine Objektversion in eine andere Version umwandelt. Allerdings müssen Sie dies aufrechterhalten, was für Sie mit großem Aufwand verbunden ist.
Wäre es nicht schön, wenn der verteilte Cache irgendwie für Sie die Versionskompatibilität übernehmen würde? Also, NCache tut genau das. NCache bietet Ihnen eine Objekttransformation auf Binärebene zwischen verschiedenen Versionen. Sie können verschiedene Versionen über eine XML-Konfigurationsdatei zuordnen und NCache versteht, wie man von einer Version in eine andere übergeht.
Außerdem seit NCache speichert alle diese verschiedenen Versionen in einem Binärformat (anstelle von XML), die Datengröße bleibt sehr kompakt und klein und daher schnell. In einer Umgebung mit hohem Datenverkehr führt die Objektgröße zu einem erheblichen zusätzlichen Bandbreitenverbrauch, der wiederum mit eigenen Kosten verbunden ist.
Hier ist ein Beispiel für NCache config.ncconf mit Klassenversionszuordnung:
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> |
Wie funktioniert NCache TU es?
In der Datei config.nconf, die Sie oben sehen, werden Sie feststellen, dass für die Employee-Klasse zuerst eine Reihe von Attributen definiert ist. Dies sind versionunabhängige Attribute und erscheinen in allen Versionen. Dabei handelt es sich eigentlich um eine Obermenge aller Attribute, die in verschiedenen Versionen vorkommen. Darunter legen Sie versionenspezifische Attribute fest und ordnen diese den versionenunabhängigen Attributen darüber zu.
Nehmen wir an, Sie haben die Employee-Version 1.0.0.0 gespeichert, die eine Teilmenge der Employee-Version 2.0.0.0 enthielt. Wenn nun eine andere Anwendung versucht, denselben Mitarbeiter abzurufen, ihn aber als Version 2.0.0.0 sehen möchte, NCache weiß, welche Attribute der Version 2.0.0.0 mit Daten gefüllt werden müssen und welche leer bleiben sollen.
Zweitens werden Sie in der obigen Beispielkonfiguration feststellen, dass die Mitarbeiterversion 2.0.0.0 das Adressfeld nicht enthält, obwohl Version 1.0.0.0 es hat. Also, in diesem Fall wann NCache versucht, den im Cache gespeicherten Mitarbeiter 1.0.0.0 zu lesen und ihn in die Mitarbeiterversion 2.0.0.0 umzuwandeln, weiß er, dass das Adressfeld nicht kopiert werden darf, da es in dieser neueren Version nicht vorhanden ist.
Es gibt viele andere Szenarien NCache erledigt alles reibungslos für Sie. Weitere Informationen hierzu finden Sie in der Online-Produktdokumentation.
Das Beste daran ist schließlich, dass Sie keinen Serialisierungscode schreiben oder Codeänderungen an Ihrer Anwendung vornehmen müssen, um dies zu verwenden NCache -Funktion NCache hat einen Laufzeitcode-Generierungsmechanismus implementiert, der zur Laufzeit In-Memory-Serialisierungs- und Deserialisierungscode Ihrer Klassen generiert und die kompilierte Form verwendet, die sehr schnell ist.
Zusammenfassend verwenden NCache Sie können jetzt verschiedene Objektversionen zwischen Ihren Anwendungen teilen, ohne Ihren Anwendungscode zu ändern.