Konzeptfrage: Datenobjekte syncronisieren

[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.