C# Desktopanwendung soll nun Online Synchronisierung bereitstellen, wie am besten?

Guten Morgen,

seit einigen Tagen beschäftigt mich ein Problem meiner eigentlich für den Desktop vorgesehenen Anwendung, nämlich das immer öfter die Daten auch per Smartphone abrufbar, editierbar und auch löschbar sein sollen.
Meine Anwendung ist eine WPF Desktopanwendung mit einer Embedded Datenbank. Im Moment handelt es sich um Microsoft SQL Server Compact 4.0 als Datenbankanbindung.

Ich stelle mir die allgemeine Frage, welches Konzept am besten passt. Ich hatte überlegt das Ganze auf eine MySQL Datenbank auf einem Server im Netz erreichbar auszulagern, so dass die Desktop Application als auch die Smartphone App, wenn dann später programmiert zugreifen können.

Auf eine Web Application würde ich gerne ganz verzichten, da ich das Ganze nicht nochmal von Null an neu programmieren möchte. Ich denke aber das die Umsetzung in eine PHP Webanwendung von Vorteil wäre. Ich muss aber auch dazu gestehen, dass falls eine Webanwendung unabdingbar wäre ich kein Sicherheitsexperte auf dem Gebiet bin, die Datenbank und die Anbindung insbesondere gut abzusichern.

Wie würdet Ihr an das Problem heran gehen? Welche Ideen hättet ihr?

Viele Grüße und einen schönen Sonntag

Ich verstehe den Unterschied zwischen Web Application und PHP Webanwendung nicht. Grundsätzlich brauchst du irgendeine Art Zentrale Instanz / Datenbank mit der sich die Clients synchronisieren. Und dann eine entsprechende Schnittstelle dazu.
Aus Sicherheits- und wegen OS Restriktionen greift man in der Regel nicht direkt auf die Datenbank zu. Du könntest ja den Port der (My)SQL Datenbank freigeben und von den Clients direkt anfragen hinschicken. Empfiehlt sich aber nicht, ausserdem möchtest du ja auch eine Art Rechtemanagement haben. Also brauchst du eine Schnittstelle. Hier wird eben oft eine Web Application oder einfach REST Schnittstelle eingesetzt, da dies auf allen Client OS verfügbar ist in der Regel.
Du kannst natürlich auch selber ein Protokoll entwickeln (nicht zu empfehlen) oder dir etwas anderes ausschen. Normalerweise nimmt man ein Framework das zum einen Sicherheit bietet und mit dem man sich auskennt (damit die Entwicklung schneller geht).

Ob du das jetzt als Java EE mit einem Application Server implementierst, oder node.js nutzt ist im Endeffekt egal. Nimm die Technologie mit der du dich besser auskennst. Wobei node.js oder Python REST Frameworks natürlich mehr lightweight sind.

Es gibt keinen Unterschied, ich meinte damit das ich es mir gern ersparen wollen würde die Anwendung in PHP noch mal neu zu programmieren und dann als Webanwendung bereit zu stellen, das ich z.B. eine Smartphone App habe die als Frame dient für die Webanwendung.

Das heißt ich biete eine REST Api an mit der dann der Datenaustausch von statten geht? Im Grunde bedeutet das aber, das ich meine Desktopanwendung um programmieren muss, da ich im Moment das EntityFramework nutze um auf die Datenbank zuzugreifen.

​Danke schon mal für den Tipp.

Edit:

Würde es nicht genügen wenn mein MySQL Server auf einem Webserver läuft und die Anwendung auf die Datenbank im Netz zugreift? Natürlich richtig konfiguriert und abgesichert? Also sprich man authentifiziert sich in der Desktopanwendung am Datenbankserver und bekommt so dann einen Zugriff auf seine Daten in der Datenbank?

Nein, wie soll denn die Authorisierung auf die Daten aussehen? Inperformant wäre das auch, da die Latenz dann vergleichweise hoch ist und sich diese bei sequentiellen Abfragen summiert, was meines Wissens nach gerade beim Entity Framework gerne passiert.

Und was wäre dein Gegenvorschlag?

Wie Falc bereits gesagt hat: Eine REST Schnittstelle

Und wie löst das das Latenzproblem?

Ein entsprechendes framework verwaltet die Verbindungen zur Datenbank. Da musst du dir normalerweise keine Gedanken machen. Google doch mal nach Flask Rest Tutorial. Da sollte es etwas geben.

Das was du vorgeschlagen hast, ist genau wie man es nicht machen sollte. Unsicher direkten zugriff auf die Datenbank zu haben

Ja das habe ich mir schon gedacht das es unsicher ist, leider habe ich keine Erfahrung damit wie man es richtig macht. Wenn ich jetzt selber ne REST Schnittstelle schreiben würde, dann wäre die genauso unsicher, d.h. ich muss auf eine Schnittstelle zurück greifen, die es schon gibt, da das Neuerfinden des Rades ja auch keinen Sinn macht.

Kann mir Jemand etwas performantes empfehlen? Und eine andere Frage, wäre was passiert mit dem Entity Framework, das müsste ja dann raus fliegen und die Datenbank damit aktualisieren etc kann ich dann ja auch nicht mehr.

Ich arbeite im Moment mit dem CodeFirst Ansatz was klasse funktioniert.

Und eine andere Frage, wäre was passiert mit dem Entity Framework, das müsste ja dann raus fliegen und die Datenbank damit aktualisieren etc kann ich dann ja auch nicht mehr. ​

Zum Vergrößern anklicken....

Du lagerst doch einfach nur aus der Applikation deine Datenschicht/Repositories deiner Anwendung auf eine externe Anwendung aus. Dise kann selbstverständlich weiterhin Entity-Framework benutzen.

The Ripper schrieb:

Und wie löst das das Latenzproblem?

Zum Vergrößern anklicken....

Indem 10 Sequentielle Anfragen an localhost wenn es hochkommt eine Latenz im einstelligen Millisekundenbereich erzeugt, während es über mehrere Hops dann schon gerne mal ne halbe Sekunde ist.

Und wenn man die Daten dann Clientseitig (sprich nicht direkt in der Datenbank) aggregiert, müssen zusätzlich noch die ganzen Daten übertragen werden, statt einfach nur das Ergebnis.

Vielleicht waere ein Headless CMS etwas fuer diesen Fall.
z.B. GraphCMS (Service) oder Directus (Self-Hosted)
Beide stellen dir deine Daten als REST API zur Verfuegung.
Mit Directus kannst du deine bisherige Datenbank Struktur wahrscheinlich beibehalten,
bei GraphCMS musst du alles neumachen.

Schau dir mal https://swagger.io und/oder https://grpc.io an.

Ersteres ist eine Rest API Development Plattform, bei welcher du deine API als YAML Code beschreibst und dir einen Server und Client generieren lassen kannst (C# ist leider nicht dabei).

gRPC ist ein RPC Framework von Google, was deinen Vorstellungen wohl am ehesten entgegen kommt. Ob sich das mit dem Entity Framework verträgt, kann ich dir nicht sagen, da ich C# nicht kenne. Das RPC Konzept ist aber Sprachenübergreifend und im Falle von gRPC beschreibst du deinen Service und die Entitäten dank Protobufs sogar in einer eigenen Sprache, welche faktisch in jede beliebige Programmiersprache übersetzt wird. Auf dem Handy wirst du ja kein C# einsetzen. Ich denke, das wäre die für dich interessanteste Lösung.

Danke für die vielen Antworten, zur Zeit habe ich mich entschieden das Ganze neu zu programmieren in php mittels Laravel.

Was auch ziemlich flott von der Hand geht, sobald man Laravel aufgesetzt bekommen hat und es auch etwas verstanden hat.
Das schöne ist, es gibt wunderbar viel Dokumentation zu Laravel so das man immer irgendwie sein Problem gelöst bekommt.