Konzeptfrage: Datenobjekte syncronisieren

[stahli]

Es ist noch nicht soweit, aber ich überlege, welches Konzept das beste wäre, meine Daten später einmal über ein Netzwerk/Internet zu syncronisieren.

Folgender Stand:

Ich halte Daten zur Laufzeit im Hauptspeicher in Objekten. Diese verwalten die Daten und enthalten die Geschäftslogik. Zur Laufzeit wird eine Datei geladen und die darin definierten (Daten-)Objekte werden erzeugt (ähnlich einer dfm).
Die Datenmenge ist so groß, dass sie im Speicher gehalten werden kann.

In einer GUI-Schicht werden (anbhängig von den vorliegenden Datenobjekten) dynamisch passende sichtbare Objekte erzeugt, die die Daten darstellen und eine Bearbeitung ermöglichen (anbei mal zwei Screenshots). U.a. gibt es einen Designer, auf dem Objekte hinzugefügt, verschoben und gelöscht werden können. Diese Manipulationen werden dann an die Datenschicht weitergeleitet.

Lokal funktioniert das alles schon mal wunderbar.

Nun möchte ich (später einmal) eine Möglichkeit anbieten, im Netzwerk/Internet mit mehreren Clients auf die gleichen Daten zuzugreifen. Clients sollen dann die Berechtigung nur zur Einsicht oder auch direkt zur Bearbeitung der Daten erhalten können.

Ursprünglich hatte ich die grundsätzliche Idee, eine einfache Datenbank als zentralen Datenspeicher zu nutzen. Die Getter und Setter meiner Objekte müssten dann "einfach" auf die Datenbank statt auf Ihre eigenen Felder zugreifen.

Ich bräuchte 2 Tabellen:
- TableStructure bildet die Objektstruktur der ineinander verschachtelten Objekte ab: ObjectId, ObjectClass, OwnerId
- TableData enthält die Objektdaten: ObjectId, PropName, PropText
Die Client-Objekte müssten dann über Zeitstempel immer prüfen, ob in der Datenbank Änderungen vorliegen.
Ein besonderes Problem ist die Konfliktbehandlung, wenn z.B. von einem Client aus ein Objekt gelöscht wird (da wäre z.B. ein Feld "Destroyed" denkbar). (Gleichzeitige schreibende Zugriffe sind aber - zumindest in meinem aktuellen Projekt - kaum zu erwarten).

Ich hatte so etwas mal grob angetestet und das sah ganz erfolgversprechend aus. (Wenn ich eine Komponente auf meinem PC verschoben habe, wurde die auch auf dem Laptop im Client verschoben und umgekehrt - also grundsätzlich sollte das machbar sein).


Anscheinend könnte man aber auch Datasnap für die Kommunikation für solche Zwecke nutzen!? (Videos ganz unten)
Im Beispiel wird ein kleiner Chat aufgebaut. Aber man kann ja auch Objekte über JSON übertragen!? Bzw. müssten die Clients einmal alle Objekte erhalten und sich dann gegenseitig über alle Änderungen informieren...
Der "Server" wäre der erste Rechner, der die Daten lädt. Die anderen würden sich als Clients anmelden (mit Lese- oder auch Schreibrechten).


Was wäre die beste Richtung - wenn ich unbedingt bei meinen Datenobjekten bleiben will.
(Eine klassische Datenbankanwendung kommt für mich nicht in Frage. Der User soll alles haptisch bedienen können und die Geschäftslogik soll in den Objekten bleiben.)


Die Datenbank(zwischenspeicher)lösung würde ich mir wohl grundsätzlich zutrauen.
Die Variante mit DataSnap klingt interessanter - wenn es denn so funktioniern kann.

[mjustin]

Object Caches wie memcached und Message Broker (Microsoft Message Queue, ActiveMQ, HornetQ, RabbitMQ, ...) könnten die zentrale Datenhaltung und sofortige Benachrichtigung aller Clients im Netzwerk über Änderungen vereinfachen, und auch die Objekte selber (JSON oder XML serialisiert) übertragen.

Ein Vorteil wäre, dass nicht die Clients regelmäßig den zentralen Server abfragen müssen, sondern der Server den Clients (allen oder nur denjenigen, die an bestimmten Objekten oder Objektgruppen, oder sonstigen Ereignissen) gezielt aktiv die gewünschten Informationen sendet.

Message Broker können Objekte die noch im Transit (noch nicht zugestellt) sind persistieren, so dass sie auch noch zugestellt werden nachdem der Broker heruntergefahren wird, und bieten transaktionalen Nachrichtenaustausch.

Viele Message Broker sind Open Source Lösungen die schon viele Jahre Praxiserfahrungen hinter sich haben, wie Apache ActiveMQ, oder in großen Serversystemen eingesetzt werden (Oracle OpenMQ).

Sie sind meist sehr schnell installiert (downloaden, start.bat ausführen).

Für Chat-ähnliche Anwendungen sind sie ideal, ein Client kann zum Beispiel auch Nachrichten abrufen die andere Teilnehmer an den Chatroom gesendet haben während er offline war (mit sogenannten 'Durable Subscriptions'), der Broker versucht dann so viele noch nicht zugestellte Nachrichten auszuliefern wie möglich.

Datenbanken sind nicht immer die ideale Lösung, vor allem wenn es um aktive und flexible Benachrichtigung vieler Clients geht, die müssten sonst immer wieder aufwendig Tabellen pollen. Auch DB-Events sind eingeschränkt und von System zu System unterschiedlich.


Cheers,
Michael

[Jumpy]

Ich hab zuwenig Ahnung um hier sinnvoll beitragen zu können, hab aber mal eine Frage. Wo/Wie speicherst du deine Objekte/Daten, wenn der Rechner aus ist? Oder geht es nicht um persistente Daten und Objekte?

[omata]

Zitat von stahli:

Der "Server" wäre der erste Rechner, der die Daten lädt. Die anderen würden sich als Clients anmelden (mit Lese- oder auch Schreibrechten).

Und was ist, wenn genau auf diesem Rechner dein Programm beendet wird?

[stahli]

@mjustin
Das klingt nicht schlecht - im Grunde, wie ich mir das mit DataSnap vorgestellt habe. Zumindest die Kommunikation wäre m.E. wohl damit realisierbar, aber wohl kein Transaktionsspeicher.
Muss ich mir später mal genauer anschauen.

Grundsätzlich könnte der MainClient (Server) eine Datei öffnen. Später könnten sich dann Clients "anmelden" und sich die aktuellen Objekte schicken lassen. Ab dann werden alle Änderungen an alle Clients weiter geschickt.

@Jumpy
Die Daten liegen in einer Textdatei, die die gesamte Struktur abbildet:

Code:

!ProgramName=Olympic
!ProgramVersion=(V. 0.3.1j-)
!FileVersion=0
<TournamentEvent=20110614204644842-20110614204808441-0000005353
  Name=30. Kaltenkirchener Badminton Mannschaftsturnier 2009
  <State=20110308225432075-20110308225432422-0000000005
  >
  <Sport=20100827212547328-20100827212547942-0000000002
    Name=Badminton
    SportPlaceName=Feld
    <NumeratorList=20100827212547328-20100827212547942-0000000003
      <Numerator=20100827212547328-20100827212702853-0000000005
        Name=Rallypoint
        Activate=True
        PointName=Bälle
        WinSetCount=2
        Definition=0..19:21;20..28:+2;29:30
        PlanDuration=30
      >
      <Numerator=20100827212547328-20100827212808350-0000000006
        Name=alte Zählweise bis 15
        Activate=True
        PointName=Bälle
        WinSetCount=2
        Definition=0..14:15;14..16:17
        PlanDuration=40
      >
      <Numerator=20100827212547328-20100827212845934-0000000007
        Name=alte Zählweise bis 11
        Activate=True
        PointName=Bälle
        WinSetCount=2
        Definition=0..10:11;10..12:13
        PlanDuration=25
      >
    >
    <DisciplineGroupList=20100827212547328-20100827212547942-0000000004
      <DisciplineGroup=20100827212547328-20100827212930462-0000000008
        Name=2HD, DD, 3HE, DE, Mix
        <DisciplineList=20100829114444357-20100829114444984-0000000001
          <Discipline=20100829115644843-20100829115652374-0000000001
            Name=1.HD
            NameMirror=1.HD
            GameTypeNumber=1
            GameType=gtMD
            Numerator=20100827212547328-20100827212702853-0000000005
          >
          <Discipline=20100829115731646-20100829120222558-0000000001
            Name=2.HD
            NameMirror=2.HD
            GameTypeNumber=2
            GameType=gtMD
            Numerator=20100827212547328-20100827212702853-0000000005
          >
          <Discipline=20100829115731646-20100829120226174-0000000002
            Name=DD
            NameMirror=DD
            GameTypeNumber=0
            GameType=gtWD
            Numerator=20100827212547328-20100827212702853-0000000005
          >
...

@omata
Im Grunde ist der "MainClient" nur ein normaler Client, der lediglich die Textdatei geöffnet hat, die die zu nutzenden Daten enthält.
Wird MainClient geschlossen, haben alle anderen Clients noch ihre Objekte in ihrem Speicher und können miteinander kommunizieren (egal, ob z.B. DataSnap oder eine SQL-Datenbank zum Datenaustausch genutzt wird).
Wie gesagt, ich bin erst mal dabei, mir eine Meinung zu bilden.
Ich will keine weltweite Datenbankanwendung erstellen, sondern eine objektorientierte, normalerweise lokale Anwendung, die aber ihre Daten u.U. mit anderen Clients teilen soll.

Im aktuellen Projekt soll eine Turnierleitung eine Turnierverwaltung abwickeln und 1-2 weitere Rechner als Auskunfssystem für die Spieler bereitgestellt werden. Auch ein zweiter Rechner für eine zweite Turnierleitung wäre denkbar.

[stahli]

Da es im "C# oder Prism"-Thread gerade mal angerissen wurde, mal eine Frage an Euch (insbes. natürlich Phoenix), wie man mein Anliegen (komplett mit Objekten arbeiten, diese aber zwischen mehreren Clients syncronisieren) mit Prism angehen würde.

Eine Datenbank als Datenlager (ohne Logik) wäre denkbar, eine Objektsyncronisation auf direktem Wege aber wünschenswerter (damit die schönen Objekte nicht in Tabellen verhackstückelt werden müssen ;.)).

Welche Stichworte sollte man diesbezüglich mal nachlesen?

Ursprünglich hatte ich überlegt, mein Projekt mit Prism aufzubauen. Aufgrund der hohen Lernkurve habe ich das dann aber verworfen.
Was sich auf jeden Fall mal interessand und sehr nützlich anhört, wäre das LinqToObjects.

Wie regelt man aber sinnvoll eine Datensyncronisation mit Prism (das wäre ja letztlich ein ähnlicher Anwendungsfall wie bei Online Games)?

[Phoenix]

Hi,

hab den Thread ja gar nicht gesehen, obwohl ich direkt angesprochen wurde. Mea Culpa.

Wie bekommt man Objekte zwischen einer / mehreren .NET Anwendungen synchronisiert?
Da gibts mehrere Ansätze. Der erste wäre .NET Remoting. Ist Uralt, sowas ähnliches wie COM, relativ kompliziert und langsam. Geht, würde ich aber nicht empfehlen.

Dann kann man Objekte mittels Serialisation (Binär oder XML, sowie selbst implementierte Serialisierer) übers Kabel schicken, oder den Datenbankzugriff selber mittels Services bereitstellen. Mehr gibts eigentlich nicht unmittelbar in .NET. Mit dem Microsoft Enterprise Library kann man sich aber auch schon sogenannte Application Blocks so ähnlich wie Komponenten einbinden, die da noch mehr bieten. Für die ersten beiden Möglichkeiten gibt es in .NET schon Hausmittel. Die Kommunikation im ersten Fall muss man hier über Sockets oder Webservices manuell machen. Für den zweiten Fall gibt es WCF Data Services, die dann auch schon den Datenzugriff wegnehmen.

Die Idee der DTO's (Data Transfer Objects) ist der, dass Du im Hintergrund einen OR/Mapper hast, der Dir den Datenzugriff auf dem Server komplett Wegkaspelt, und nur normale Objekte anbietet gegen die Du programmierst. Diese sind dann auch ohne Abhängigkeit zur Datebank serialisier- und Übertragbar.

Die Wahl und Bedienung des OR/M (bis auf WCF Data Services), die ganze Logik wann Du wie Daten synchronisierst bleibt aber in den Fällen immer bei Dir hängen.

Mittels N-Tier Frameworks wie Du mit DataSnap schon eines angesprochen hast, kannst Du dann den Zugriff auf diese Dienste noch einfacher gestalten, weil die einfach noch mehr von der Komplexität (und den OR/M) wegkapseln. Neben DataSnap gibts z.B. DataAbstract (etwas billiger, Performanter und flexibler in der Programmierung). DataSnap hat keinen OR/M sondern arbeitet Tabellenbasiert. DataAbstract bietet mit LINQ to DA dann aber auch eine objektbasierte Möglichkeit die Daten zu manipulieren.

Ziel von den ganzen Frameworks ist es, Dir genau den Ärger mit dem Datenzugriff und der Synchronisation zu ersparen (sofern Du nicht auf die Idee kommst, Daten selber länger auf dem Client zu cachen). Dafür bieten Sie Dir dann zusätzlich noch einige extra Features (WCF Data Services und DataAbstract z.B. LINQ in den Sprachen in denen das Unterstützt wird), Caching inkl. passender Algorithmen die den Cache auch zum richtigen Zeitpunkt verwerfen, Auswahl des Transports (wie sollen die Daten übers Netz? Schnell (meist binär), Langsam & lesbar? Nur diffs? Protocol Puffers? OData? JSON? REST?) sowie meistens noch Logging, Transaktionshandling, Security, Testmöglichkeiten ect. Das ganze drumrum was sonst Manuell gemacht werden muss.

Im übrigen scheitern ausnahmslos alle solche Systeme gleichermassen an Massendatenverarbeitung. Dafür sind sie einfach nicht konzipiert. Das heisst wenn Du für irgendwelche Auswertungen oder Massenoperationen jede Menge an Datensätzen durchnudeln musst, lasse das den Server machen. Du wirst sonst Deines Lebens nicht mehr froh. Hierzu brauchst Du dann aber noch die Möglichkeit, auch eigenen Code im Server unterzubringen und diesen entsprechend gesichert auszuführen und das Ergebnis an den Client zu liefern.

Die ganze Sache hat halt eine gewisse Komplexität, die erstmal erschlagen werden will wenn man wirklich eine mehrschichtige Anwendungen hochziehen will.