Wie teilen Sie Objekte über Prozesse in .Net?

Question

Ich versuche, .net-Objekte über separate Prozesse zu "teilen". Ich habe einen Prozesstyp, bei dem es sich um einen Webdienst handelt, der eine Reihe von Domänenentitäten manipuliert. Ein anderer Prozesstyp ist ein Fensterdienst, der eine automatische Stapelverarbeitung für denselben Objektsatz durchführt.

Über die typische Lösung hinaus, die DB als gemeinsamen Raum zu haben, in dem beide Arten von Prozessen die Objekte lesen/schreiben, könnte eine bessere, verteiltere Architektur sein, damit diese verschiedenen Prozesse die gleichen Objekte sehen und bearbeiten können.

Ich habe überlegt, einen verteilten Cache als freigegebenen Speicher für Objekte zu verwenden, aber Objekte und ihre Beziehungen nicht vollständig unterstützt. Objektgraphen, die in einen verteilten Cache eingefügt werden, werden abgeflacht und Objekte werden in mehreren getrennten Kopien gespeichert.

Ist ein "Messaging-Bus" der richtige Weg, die Prozesse einander aktualisierte Kopien der Objekte senden zu lassen?

Oder gibt es andere Lösungen insgesamt zu berücksichtigen?

Answer 1

Ich würde vorschlagen, WCF-Dienste zu verwenden. Für die lokale Verwendung (Aufruf vom Windows-Dienst) können Sie netNamedPipeBinding verwenden. Das erlaubt Ihnen, diese beiden Prozesse physisch in Zukunft zu trennen.

Answer 2

Sie müssen entscheiden, welcher Ihrer zwei Dienste oder möglicherweise ein dritter, noch nicht geschriebener Dienst, Ihre autoritative Quelle für Ihre Domänenobjekte ist.

Ein Remoting- oder WCF-basierter Satz von Diensten, die von der autorisierenden Quelle verfügbar gemacht werden, sollte die zentrale Position für Ihre Objektdiagramme bereitstellen. Ich denke jedoch, dass Sie damit beginnen, einfach einen verteilten Cache für Ihre Objekte zu erstellen.

Haben Sie die Velocity Project berücksichtigt?

Answer 3

In unseren Projekten haben wir ScaleOut StateServer (ein kommerzielles Produkt - www.scaleoutsoftware.com) verwendet, um verteiltes Caching/Replikation von Objekten in einer Serverfarm zu ähnlichen Zwecken durchzuführen. Dies war sehr effektiv, obwohl die Verwendung von Objekten (De-) Serialisierungskosten verursacht, daher vereinfachen wir in vielen Fällen das, was wir speichern, nach Möglichkeit nur auf Zeichenfolgenwerte. Wir haben das Velocity-Projekt noch nicht vollständig evaluiert, da unsere Nutzung bereits vor dem Bestehen begonnen hat und wir keine Zeit oder zwingende Gründe haben, einen Wechsel in Betracht zu ziehen, aber das erfordert offensichtlich einige Untersuchungen, wenn Sie gerade sind jetzt beginnend.

Edit: Ich habe in der Tat den wichtigen Teil über die Frage - die Abflachung der Objektreferenzen. Dies kann Dinge übermäßig komplizieren oder andere Nachteile haben, aber was ist, wenn Sie den Ansatz des Datenbankspeichers in Ihrem verteilten Cache genauer simulieren (indem Sie eine einzelne Kopie jeder einzelnen Objekteinheit speichern und losere Referenzen verwenden, um diese zu verknüpfen) Entitäten zusammen)?

Beispiel: Sie haben eine Klasse "Gruppe", die eine "Leader" -Eigenschaft und eine "Members" -Sammlung enthält, die alle Objekte enthalten, die Instanzen Ihrer "Person" -Klasse sind. Sie müssen die benutzerdefinierte Serialisierung verwenden, um sie auszuführen, und nichts wird Probleme mit Nebenläufigkeit/schmutzigen Updates auf magische Weise lösen, aber die Idee dahinter ist, dass Sie in den verteilten Cache tatsächlich alle individuellen "Personen" -Instanzen einfügen würden als eine flache Kopie der 'Gruppe' Instanz selbst. Diese seichte Kopie würde die normalen "Gruppen" -Eigenschaften (Name usw.) und eindeutige Bezeichner für jede darin enthaltene "Personen" -Referenz serialisieren (wie die ursprüngliche Datenbank-ID, eine GUID, einen eindeutigen Benutzernamen oder etwas anderes) und nicht Die Person Objekte selbst.Sie hätten also eine "LeaderID" anstelle des Leaders, und die Mitgliedersammlung würde als eine Liste von MitgliedsIDs serialisieren. Jede referenzierte Person wird auch als separates Objekt gespeichert. Hier kommt die Nebenläufigkeitstrickiness ins Spiel.

Bei der Deserialisierung (oder beim Zugriff abhängig von Verwendungsmustern) würde die flache Kopie der Gruppe allen ID-Referenzen folgen und diese Referenzen mit den realen Personenobjekten, die separat im verteilten Cache gespeichert sind, erneut hydratisieren. Sie müssten Sperrmechanismen implementieren, um sicherzustellen, dass Updates für diese Objekte, die von vielen verschiedenen Gruppen gemeinsam genutzt werden können, sicher sind. Sie benötigen außerdem einen Versionsverwaltungsmechanismus und eine "Dirty Check", wenn Sie Änderungen am Person-Objekt im verteilten Cache erneut lesen/erfassen müssen.

Es scheint ziemlich kompliziert, aber das ist der allgemeinste Ansatz, den ich denken könnte, ohne die Besonderheiten Ihres Anwendungsfalles zu kennen.