Laden...

Alternative zu AzureMobileService, wenn man eine lokale DB mit Azure DB synchronisieren will?

Erstellt von manullino vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.969 Views
manullino Themenstarter:in
371 Beiträge seit 2008
vor 6 Jahren
Alternative zu AzureMobileService, wenn man eine lokale DB mit Azure DB synchronisieren will?

verwendetes Datenbanksystem: <MSSQL, SQLite>

Hallo zusammen,

Gibt des denn eine Alternative zu AzureMobileService, wenn man eine lokale Datenbank mit Azure DB synchronisieren will?

Hintergrund: Ich habe mit EF Core und dem .NET Standard 2.0 Projekt Type eine Basis Library erstellt die ich unabhängig von der verwendeten GUI verwenden koennte. Ich mochte eine App für Windows (WPF), Anriod und IOS entwickeln.

Vielen Dank,
Manullino

16.830 Beiträge seit 2008
vor 6 Jahren

Nein, weil das sowieso keine gute Idee war.
Daher gilt der AzureMobileService mittlerweile auch als obsolete.

Eine App sollte niemals mit einer Datenbank direkt kommunizieren. Niemals. Niemals.
Davon abgesehen, dass das unsicher ist, schafft es mehr Probleme als Lösungen.

T
2.223 Beiträge seit 2008
vor 6 Jahren

Der beste und sicherste Ansatz bei Apps + zentraler DB ist immer folgender.

1.DB
2.Webservice/WebAPI mit Zugriff auf DB
3.App mit Anbindung an Webservice/WebAPI + Speicherung der Daten in lokaler DB(Sqlite etc.)

So hast du gleich mehrere Vorteile.
Auch wenn der Aufwand größer ist, so kannst du deine DB sicher von außen über den Webservice/WebAPI abschotten.
Ebenfalls kannst du mit Caching dann die Last der DB entlasten und auch die Verbindungen zur DB begrenzen.

Du lieferst deine Datenbank und somit die Daten deiner Nutzer direkt aus, wenn du deine DB direkt ins Netz hängst.
Hier musst du immer, sobald deine Daten in freie Wildbahn abwandern sollen, eine Schnittstelle vor die DB schalten um diese eben abzutrennen von der öffentlichkeit.
Deine DB sollte dann auch nur über ein internes Netz erreichbar sein, nur dein Webserver darf dann neben dem internenNetz für den DB Zugriff auch ein öffentliches Netz zum Zugriff von extern haben.
Hier liegt es in deiner Verantwortung dich auch um den Datenschutz zu kümmern!

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

manullino Themenstarter:in
371 Beiträge seit 2008
vor 6 Jahren

Hallo zusammen,

vielen Dank für Eure Antworten.

Vielen Dank zur Erläuterung der Architektur, das war aber gar nicht die Frage. 😉
Wie von Euch beschrieben, soll die Kommunikation mit Azure auch per Webservice stattfinden.

Nur wie wird/soll die Synchronisation umgesetzt werden, da finde ich eben nur den Verweis zu AzureMobileService?! Das ist das eigentliche Problem.

Vielen Dank,
Manullino

16.830 Beiträge seit 2008
vor 6 Jahren

Du sprichst von lokaler DB Sync mit Azure DB. Das war die Frage und darauf beziehen sich beide Antworten.
Ob Azure oder nicht, spielt bei der Software Architektur der potentiellenLösung übre APIs hier keine Rolle.

Wie Du am AzureMoibileService siehst (zB GitHub), hat sich da seit fast 2 Jahren nichts mehr wesentlich geändert.

Wenn das Deine Frage nicht getroffen hat, dann präzisiere sie bitte.

manullino Themenstarter:in
371 Beiträge seit 2008
vor 6 Jahren

Ist das jetzt gut oder schlecht, wenn sich fast 2 Jahren nichts mehr auf GitHub getan hat?!

Meine konkrete Problematik/Frage:
Eine UWP/Android/IOS App hat eine (via EF Core angebundene) lokale offline Datenbank, diese möchte ich mit einer Azure Datenbank synchronisieren. Wie stellt man das an?

Vielen Dank,
Manullino

16.830 Beiträge seit 2008
vor 6 Jahren

Und genau darauf wurde bereits geantwortet.

Eine UWP/Android/IOS App hat eine (via EF Core angebundene) lokale offline Datenbank, diese möchte ich mit einer Azure Datenbank synchronisieren. Wie stellt man das an?

Gar nicht. Das solltest Du lassen. Das ist ein sehr unsicherer Wunsch.

Eine App sollte niemals mit einer Datenbank direkt kommunizieren. Niemals. Niemals.
Davon abgesehen, dass das unsicher ist, schafft es mehr Probleme als Lösungen.

Was Du machen kannst ist, Ergebnisse einer API in einer lokalen Datenbank cachen.
Deine Datenbank in der Cloud sollte von aussen nicht mal erreichbar sein. Alles andere ist unsicher.

Wenn sich in Sachen Software 2 Jahre nichts getan hat.. na, was ist es dann wohl?
Gut vermutlich nicht 😉

manullino Themenstarter:in
371 Beiträge seit 2008
vor 6 Jahren

Hallo Abt,

vielen Dank für die Nachricht. Jetzt ist mir klar warum wir ein bisschen aneinander vorbei gesprochen haben. Es lag am Wort "synchronisieren".

Du würdest die Azure Daten lokal cachen, ich will die lokalen Daten zu Azure synchronisieren. Im Endeffekt ist es das selbe, die Daten sollen im Server und auf dem Client die selben sein.

Vielleicht habe ich auch deshalb kaum etwas bei Google gefunden, weil ich nach „synchronisieren“ gesucht haben.

Hast Du etwas zur Hand, wie man Azure Daten lokal cachen kann?

Vielen Dank,
Manullino

16.830 Beiträge seit 2008
vor 6 Jahren

Prinzipiell wurst ob Du Daten zu Azure bringst oder davon abholst: eine Direktverbindung auf die Datenbank solltest Du lassen.
Du solltest (immer noch) über eine API (=> Web Service) gehen.

manullino Themenstarter:in
371 Beiträge seit 2008
vor 6 Jahren

Habe oben bereits geschrieben, dass die Azure DB hinter einem Webservice sein soll.

Wie von Euch beschrieben, soll die Kommunikation mit Azure auch per Webservice stattfinden.

Nur ist eben die Fragen, wie das mit dem lokalen cachen funktioniert, bzw. wie die lokalen Daten in die Clould kommen, wenn der Client offline ist. Offline DB für ein Webservice sozusagen.

T
2.223 Beiträge seit 2008
vor 6 Jahren

Wenn dein Client Offline ist, kannst du die Daten doch gar nicht in die Cloud laden.
Ohne Verbindung funktioniert dies doch überhaupt nicht.

Ansonsten sollte dein Client die Daten per Webservice an die Datenbank weiterleiten.
Der Webservice ist dann für die Speicherungen verantwortlich.
Wenn die DB offline ist, wozu willst du dann die Daten "lokal" beim Webservice cachen?
Wäre nur ein extra Overhead den du dann zusätzlich irgendwie abgleichen musst.
Der Webservice sollte dem Client in diesem Fall eher mitteilen, dass er aktuell die DB nicht erreichen kann.
Der Client muss dann die Daten vorhalten bis der Service die DB wieder erreicht und die Daten abgleichen kann.
Ansonsten muss der Service immer in einen Fehler laufen und du musst dich dann darum kümmern die DB wieder zum laufen zu bekommen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

manullino Themenstarter:in
371 Beiträge seit 2008
vor 6 Jahren

Es ist ja wohl mehr als logisch, dass ich offline keine Daten in der Clould speichern kann.

Alles was ich will, ist die Moeglichkeit lokal zu arbeiten, wenn ich offline bin. Danach sollen die Daten wieder mit Azure abgeglichen werden. Jeder kennt das doch von zig Apps die man selbst verwendet.

16.830 Beiträge seit 2008
vor 6 Jahren

Genau; und diese Arbeiten nicht mit einer Datenbank-Synchronization, sondern sie holen sich Daten von Schnittstellen und speichern diese Lokal ab.
Sowas nennt man einfache Offline-Fähigkeit und ist keine Neu-Erfindung von Apps.

Mir wäre das neu, dass das für C# so in der Form Client-seitig etwas fertiges gibt.
Bei nicht-nativen Apps (zB. Cordova) bekommst Du es prinzipiell fast geschenkt, weil das quasi im Browser und in den Frameworks schon enthalten ist.
Bei Xamarin halt nicht.

Evtl. helfen Dir die Mobile Servies.
Aber die Mobile Service SDK können nicht auf .NET Core derzeit basieren, weil dafür OData notwendig ist - und OData für .NET Core ist immer noch nicht fertig.
Daher nochmal die Betonung: von Haus aus gibt es hier für Xamarin derzeit IIRC nichts.

T
2.223 Beiträge seit 2008
vor 6 Jahren

Um die Daten dann wieder vom Client in die Cloud zu bekommen, kannst du eben über eine WebAPI/Webservice deine Daten hochladen.

Wie du dies machen willst musst du anhand deiner Daten prüfen und umsetzen.
Entweder in dem du direkt die Datenbankdateien vom Client an den Service gibst oder besser in dem du die entsprechenden Objekte an die entsprechende WebAPI/Webservice weiterleitest.

Fertige Lösungen gibt es hier nicht, muss man immer noch selbst umsetzen.
Die entsprechenden Techniken gibt es dazu schon seit Jahren, musst du also nur umsetzen und dem Client bekannt machen.
Die eigentliche Umsetzung kann dir aber keiner vorgeben, da dies von Fall zu Fall unterschiedlich sein kann.

Wenn du viele Objekte im Client hast, würde sich vielleicht auch der Upload der ganzen DB Datei lohnen.
Hier musst du dann aber sicher Stellen, dass Server und Client die selben Objekte + DB Versionen und somit die gleichen Strukturen haben.
Oder du musst deinen Code so umsetzen, dass der die neue Service Version auch mit alten Clients umgehen kann.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.