Wir versuchen, zwei Gemfire-Repositories zu machen, da es zwei verschiedene Bean-Objekte gibt, mit denen sie zu tun haben, aber wir wollen diese beiden Bean-Objekte in derselben Gemfire-Region speichern.Kann man zwei Bean-Objekte in derselben Gemfire-Region speichern?
Ist das ein richtiger Weg? Wenn "Ja", dann wie es geht?
Vielen Dank im Voraus.
... wollen wir diese beiden Bean-Objekte in derselben Gemfire-Region speichern. Ist das ein richtiger Weg?
Das ist umstritten. Es hängt jedoch wirklich von Ihren Anwendungsanforderungen und Anwendungsfällen ab. Es hängt auch von der Beziehung zwischen den Objekten ab.
Zum Beispiel, wenn Sie ein Customer haben, welche sich (ist-a) Person dann sowohl Customers und People in der gleichen Region speichert, kann nicht so schlimm sein scheinen.
Aber, wenn Sie Customers und sagen Purchases speichern, wo ein Customer zusammengesetzt ist, oder „hat-eine“ Set/Liste der Purchases, dann ist die schwerer zu verdauen. Es erschwert auch die Abfrage dieser Region, da die (OQL) -Abfrage-Engine Objekttypinformationen auf Eigenschaften/Felder überprüft, sogar Methodenaufrufe, wenn sie innerhalb der Abfrage aufgerufen werden, was zu ClassCastExceptions und NoSuch[Method|Field]Exceptions führen könnte. Also sei vorsichtig.
Ich bin in dieser Hinsicht eher ein Purist und würde empfehlen/empfehlen, dass Sie die Anwendungsdomänenmodellobjekte in separaten Regionen behalten, besonders im Beziehungsfall "has-a". Es ist möglich, die Daten in getrennten Regionen zu speichern und die Daten (d. H. Die Regionen) weiterhin "zusammenzufassen", insbesondere für Abfragezwecke. Weitere Details finden Sie unter here.
Aber ...
All dies ist nicht zu sagen, Sie speichern Objekte von ähnlichen oder sogar verschiedenen Arten, in der gleichen Region nicht erreichen können.
Typischerweise Sie Ihr Unternehmen mit Anmerkungen versehen, Objekte Anwendungsdomäne mit dem @Region Anmerkung, welche GemFire Cache Region das Objekt angeben, gespeichert sein, wie so ...
@Region("Customers")
class Customer extends Person { ... }
@Region("Purchases")
class Purchase { ... }
Dann gehen Sie auf Ihre definieren Repositorys ...
interface CustomerRepository extends GemfireRepository<Customer, Long> { .. }
interface PurchaseRepository extends GemfireRepository<Purchase, Long> { .. }
Normalerweise, wenn SD Commons Repository-Infrastruktur und SD-Repository Erweiterung des GemFire die Repository-Schnittstellen erkennt, die Typparameter überprüft, sieht die Anwendungsdomänenobjekte (dh 0.123.& Purchase), überprüft und jene bestimmen, die Regionen zu dem jedes Objektanwendungsdomäne durch gehört ...
Entweder Erkennen und Prüfen der Attributwert @Region Annotation oder ..
Verwendung des " Einfacher Name des Domänenobjektklassennamens als Regionsname (d. h "Kunde" Region des Domänenobjekts Customer.
Das bestimmt die Region.
Wenn Sie jedoch beide Customer und Purchase Objekte wollen sich in der Region gespeichert werden, dann SD GemFire erweitert die gemeinsame Repository-Infrastruktur und ermöglicht es Ihnen, Ihre Repository-Schnittstellen mit der @Region Anmerkung zu annotieren, wie so ...
@Region("Customers")
interface CustomerRepository extends GemfireRepository<Customer, Long> { .. }
@Region("Customers")
interface PurchaseRepository extends GemfireRepository<Purchase, Long> { .. }
in diesem Fall sind beide Customer und Purchase Objekte in den „Kunden“ Region seit der @Region Anmerkung auf den Repository-Schnittstellen gespeichert werden die @Region Anmerkung auf dem einzelne Anwendungsdomäne Objekt überschreibt s.
Es gab gültige Gründe und Anwendungsfälle, um diese Funktion speziell in Spring Data GemFire zuzulassen. Weitere Informationen hierzu finden Sie unter here.
Unabhängig davon, wie Sie vorgehen, sollten Sie Ihre Optionen sorgfältig abwägen.
Hoffe, das hilft!
Prost, John