Laden...

Datensätze auf mehreren Clients synchron halten

Erstellt von Merlin_S vor 6 Jahren Letzter Beitrag vor 6 Jahren 4.080 Views
M
Merlin_S Themenstarter:in
116 Beiträge seit 2006
vor 6 Jahren
Datensätze auf mehreren Clients synchron halten

Hallo ihr lieben,
Ich stehe vor einem Problem bzw. einer Problemstellung, von der ich glaube, dass ich nicht der erste sein kann, der davor steht. Und ich möchte euch freundlich darum bitten, mir beim Googlen zu helfen oder mir hilfreiche Stichworte zu nennen. Ich bin da seit einigen Tagen relativ erfolglos.

Die Problemstellung lautet folgendermaßen:

Es gibt vereinfacht Gesprochen einen Datensatz, an welchem einige Clients innerhalb eines Netzwerk parallel arbeiten sollen. Der Datensatz besteht aus ca. 10 verschiedenen Klassen, die in Listen zu je ca. 100 zusammengefasst sind. Jedes Objekt hat ca. 10 Eigenschaften. Es soll einfach sein, das System um weitere Entitätstypen zu ergänzen, sehr Wünschenswert wäre es, wenn alles möglichst generisch gehalten wird, so dass man über MEF o.ä. Plugin-Systeme und wenig Code-Aufwand neue Entitäten hinzufügen könnte, welche dann auf gleiche Weise gehandhabt werden, ohne den eignetlichen Management-Kern anzufassen.
Dazu soll es einen Server geben, zu dem alle Clients eine dauerhafte Verbindung halten. Zum Login soll ein Client einen "Dump" des ganzen Datensatzes erhalten. Ab dann schickt er veränderte Objekte zum Server, welche diese Information in seiner eigenen Kopie einpflegt und gleichermaßen an alle anderen verbundenen Clients weiterreicht. Der Server vergibt auch allein die IDs für die einzelnen Entitäten.
Zwischen Entitäten gibt es auch die üblichen Beziehungen (1:n, m:n), welche ebenfalls Verwaltet werden sollen.

Der Server soll weiterhin eine irgendwie geartete Persistenz bereitstellen. Das ist aber ein anderes Thema.

Überlegungen bislang:*EntityFramework + Datenbank: Das Interface von EF gefällt mir sehr gut, ich stelle mir für meine Lösung etwas ähnliches vor. Leider habe ich bis auf beim SQL-Server keine schöne Möglichkeit gefunden, umgehend über Änderungen an Einträgen benachrichtigt zu werden. SQL-Server scheidet für mich leider aus. Mir ist für andere DBS (MySQL bspw.) keine Möglichkeit bekannt, Clients über durchgeführte Änderungen in der Datenbank zu benachrichten. Weiterhin soll der Server auch andere Aufgaben übernehmen, so dass man eine Verbindung zur Datenbank bräuchte und dennoch die Server-SW.

  • Eigenes "ORM", welches die Erweiterbarkeit per MEF sicherstellt (Reflection) und statt einer SQL-Datenbank halt den Server im Hintergrund hat. Mit der Persistenz hätte ich dann ein eigenes Datenbanksystem gebaut, mit allen Fiesheiten, die die Entwicklung eines solchen bietet. Möglich, aber irgendwie nicht schön. Klingt danach, als würde man das Rad zum x-ten mal neu erfinden.

Es stellen sich mir also folgende Fragen:*Gibt es etwas für meinen Anwendungsbereich schon? Wenn ja: Wonach muss ich suchen? *Wenn nein: Gibt es vielleicht DOCH eine Möglichkeit, über EF (oder einen anderen ORM) über Änderungen in Datenbanken benachrichtigt zu werden? Meiner Erinnerung nach ist das eigentlich in den meisten DBS nicht von Haus aus vorgesehen.

Da es sich um ein privates Lern-Projekt handelt wäre irgendetwas Open-Source schön. 😃

Ich bedanke mich bereits im Voraus für eure Hilfe.

Merlin

D
985 Beiträge seit 2014
vor 6 Jahren

Für die Benachrichtigung der Clients eignet sich SignalR

2.207 Beiträge seit 2011
vor 6 Jahren

Hallo Merlin_S,

im Bereich ASP.NET gibt es das bereits genannte SignalR. Das fasst vier Technologien zusammen mit Fallbacks (SSE, WebSockets, LongPolling und Forever Frame(Aber nur im IE)). Im Prinzip verwendest du SignalR und die Technologie verhandelt selber mit dem Server, was der kann. Websockets kann beispielsweise nicht jeder Server.

Benachrichtigen macht in der Regel nicht das EF, sondern der WebService davor. Im ASP.NET hast du eben mit SignalR die Möglichkeit Nachrichten rauszuschicken, auf die sie die Clients registrieren.

Im ASP.NET Core wurde zu Beginn des Jahres ein Preview von SignalR auf Core gezeigt, aber das ist noch nicht erschienen. Falls das relevant sein sollte weil du auf Core unterwegs bist.

Du kannst aber auch WebSockets direkt nehmen, ohne SignalR. Ist halt weniger komfortabel, aber möglich. Fakt ist, irgendwie muss der Server den Client benachrichtigen, was es neues gibt.

Gruss

Coffeebean

M
Merlin_S Themenstarter:in
116 Beiträge seit 2006
vor 6 Jahren

Hallo ihr beiden,

Vielen Dank für den Tipp, SignalR schaue ich mir heute Abend auf jeden Fall ein mal an.

Ich hätte aber vielleicht dazu erwähnen sollen, dass es sich nicht um eine ASP.NET-Anwendung handelt, sondern (bislang noch) um eine Windows Forms Applikation, in der nächsten Iteration soll daraus eine WPF-App werden.

Vielen Dank,
Merlin

D
985 Beiträge seit 2014
vor 6 Jahren

Das womit die Anwender arbeiten hat aber einen zentralen Punkt, wo die Daten dann ankommen.

An diesem zentralen Punkt setzt man an und kümmert sich um die Speicherung, Signalisierung, etc. Das könnte z.B. eine ASP.NET WebApi sein, die dann im Hintergrund per EF die Daten speichert und per SignalR die Signalisierung vornimmt.

M
Merlin_S Themenstarter:in
116 Beiträge seit 2006
vor 6 Jahren

Moin,
Da hast du natürlich Recht. Ich bin bloß (beruflich wie privat) noch nie mit ASP.NET in Kontakt bekommen und habe es daher bislang gar nicht in Betracht gezogen. Meines (gefährlichen halb-)Wissens nach benötigt ein ASP.NET-Projekt einen Webserver (IIS?), um zu laufen. Auf den würde ich in der Tat gern verzichten, um den Server ohne größere Umwege auf beliebigen PC ausführen zu können. Es handelt sich um ein Projekt, das nicht stationär auf einem Rechner läuft sondern den Einsatzort vermutlich relativ häufig wechselt.

Wenn sich heraus stellt, dass es doch keinen Webserver ala IIS braucht (Auch um das zu Googlen habe ich erst heute Abend Zeit 😃 ), könnte es u.U. ein nettes Lernprojekt für ASP.NET werden.

Merlin

1.029 Beiträge seit 2010
vor 6 Jahren

Hi,

naja - ich würde lieber einen Webserver aufsetzen - als dass ich ein nicht gerade triviales PeerToPeer-Netz auf eigener Basis aufstelle, worauf deine Gedanken gerade hinauslaufen.

Nur so als Wink 😉

LG

M
Merlin_S Themenstarter:in
116 Beiträge seit 2006
vor 6 Jahren

Naja, ich möchte ja eigentlich gerade kein P2P-Netzwerk haben, sondern die Daten schon an Zentraler Stelle verwalten lassen.

Merlin

16.806 Beiträge seit 2008
vor 6 Jahren

Aber wenn Du kein P2P sondern ein Client-Server System haben willst, wie Du es gerade sagst, dann brauchst Du ja einen Server und eine Anwendung auf dem Server.
Wenn nicht mit ASP.NET, womit dann? Windows Forms bzw. eine Desktop-Applikation geht hier ja nicht.

Du musst ja die Daten austauschen, wofür man i.d.R. HTTP als Protokoll und eine entsprechende Anwendung (zB API auf Basis ASP.NET) verwendet.

M
Merlin_S Themenstarter:in
116 Beiträge seit 2006
vor 6 Jahren

Windows Forms bzw. eine Desktop-Applikation geht hier ja nicht.

Huch? Das musst du mir erklären. 😃

Ich konkretisiere mal mein Anwendungsszenario:

Das ganze wird eine Art Dispositionssoftware für eine spezielle Art von Einsätzen im Umfeld einer Hilfsorganisation. Diese Einsätze werden vorab in der Software geplant und dann an mehreren Arbeitsplätzen durchgeführt.

Dafür werden 1 bis (in der Praxis maximal) 6 Computerarbeitsplätze aufgebaut, welche dann mit der Software bestückt werden. Auf einem der Rechner ODER auf einem Extra-Rechner läuft dann ein Server, zu dem sich alle anderen verbinden. Dieser Server kümmert sich darum, dass alle Arbeitsplätze den gleichen Datenstand beim Login erhalten und verteilt Updates zu allen Clients. Wir sind hier immer in einer kontrollierten, kabelgebundenen Netzwerkumgebung.

Nun soll es aber möglich sein, ohne große Kenntnisse den Server aufzusetzen. Hier stelle ich mir ein Programm vor, in welchem man ein Projekt wählt, "Start" drückt, und der Server läuft. In der Regel sind die Nutzer Laien, denen bei dem Begriff "Webserver" schon der Rauch aus den Ohren pfeift.

Es spricht ja Grundsätzlich wenig gegen HTTP als Transportprotokoll, lediglich müsste man dann die Bidirektionalität sicherstellen (WebSocket?).

Interessant ist bei der ganzen Geschichte vor allem die möglichst universelle Erweiterbarkeit durch Plugins. Hier sehe ich offenbar keinen Ernsthaften Weg an Reflection vorbei.

Liebe Grüße,
Merlin

16.806 Beiträge seit 2008
vor 6 Jahren

Ja, hab ich verstanden.

Aber wenn Du es ordentlich umsetzt, dann hat die Software, die den Server spielt, keine UI.
Deine Software soll schließlich auch laufen, wenn kein Benutzer an einem Rechner angemeldet ist - zB nach einem Neustart - und keine UI verfügbar ist (was eben bei solch einer Archtektur Client-Server auch der Fall ist).

Und dann bist Du bei Technologien wie ASP.NET oder einem Windows Service, einem Netzwerkprotokoll wie HTTP und einem Austauschformat wie zB. Json oder XML.
Ohne das sprechen wir dann doch von P2P und nicht von Client-Server.

Erweiterbarkeit geht auch ohne Reflection, je nachdem was und wie man erweitern will.

W
195 Beiträge seit 2008
vor 6 Jahren

Das hört sich alles nach einem ziemlichen Gemurkse an. Warum nicht ganz klassisch eine vernünftige Datenbank, auf die die Clients zugreifen?

P
441 Beiträge seit 2014
vor 6 Jahren

Für dein Szenario: Weil die Datenbank nicht pushen kann.

Für generell: Um den Datenbank austauschbar zu machen und den Zugriff zu kapseln.
HTTP bietet ganz andere Möglichkeiten als das Datenbank Protokoll

16.806 Beiträge seit 2008
vor 6 Jahren

Das Szenario ist doch quasi Alltag:

Es gibt eine zentrale API - in der .NET Welt eine ASP.NET Anwendung, mit denen alle Clients kommunizieren.
Diese bietet auf REST-Basis Methoden an, an die der Client Daten schicken kann sowie einen WebSocket (zB. SignalR), mit dem der Client aktiv vom Server Informationen gepusht bekommt.

Clients direkt auf die Datenbank zu lassen versucht man heutzutage eigentlich zu vermeiden.

D
985 Beiträge seit 2014
vor 6 Jahren

Clients direkt auf die Datenbank zu lassen versucht man heutzutage eigentlich zu vermeiden.

Zumal es heutzutage sehr beliebte Geräte gibt (Mobile Device) die teilweise gar nicht oder nur mit erheblichem Aufwand mit einer Datenbank direkt kommunizieren können. Per http kann quasi jedes Device kommunizieren.

Und in punkto Sicherheit sollte man zwischen Datenbank und dem Rest der Welt immer etwas zwischenschalten.

1.029 Beiträge seit 2010
vor 6 Jahren

Hi,

und falls es dir nur um den Startbutton geht - ASP.NET Core ist nicht auf den IIS angewiesen.
Alternativ kann man an Stelle von ASP.NET Core wenn's um ne WebApi geht auch durchaus auf Nancy setzen.

Hosten kannst du dann beide via:

  • Windows Service
  • Konsolenanwendung
  • IIS
  • und viele andere Optionen

Allerdings solang's um ne WebApi geht - und das ist sicher die austauschbarste Variante - würde ich auf einen der vorgenannten in Verbindung mit JSON setzen.

LG

P
1.090 Beiträge seit 2011
vor 6 Jahren

SignalR kann auch einfach in einem Dienst gehostet werden.
Software Engeniring:SignalR Self Hosting in a Windows Service

Da kannst du dann mit WindowsForms und WPF drauf zugreifen.

Wenn du später von WindowsForms nach WPF umsteigen möchtes, mach direkt eine Mehrschichtige Architektur, dann kannst du einen Teil der Klassen wieder verwenden und eigendlich kannst du auch direkt das MVVM Pattern verwenden.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

M
Merlin_S Themenstarter:in
116 Beiträge seit 2006
vor 6 Jahren

Moin moin!
Ich hatte heute dann auch etwas Zeit mich in SignalR einzulesen, und das sieht aus, als wäre es genau das, was ich brauche. Und es läuft - danke für den Hinweis - auch noch in beliebigen Anwendungen (Konsole, Service, GUI, IIS...).

Danke für eure Hilfe!

Merlin