C/S mit Objekten - Grundsatzfrage

[jobo]

@Phoenix
Das sind interessante Ideen, aber die Umsetzung halte ich doch für recht aufwändig. Was soll man hier unter Business Logik verstehen?

Ein Server ist ein Server ist ein Server. Dient z.B. dazu, referenzielle Integrität sicherzustellen. Überhaupt ist er dazu da, sämtliche Fehleingaben abzuwehren. Ein dummer Client, ohne jegliche Eingabekontrolle, sollte es nicht schaffen, Fehleingaben durchzudrücken.

Wie soll sich bspw. ein intelligenter Client als Server verhalten, ohne selbst ein komplettes Datenbank-Replikat zu halten, was ja die Validierungsgrundlage ist?
Business Logik lebt doch im gesamten Datenkontext, idR. ein Mehrbenutzersystem, das nicht selten auch automatisiert Daten aus 3. System verarbeitet, wie und auch warum sollte auf einer solchen Basis eine Business Operation im Client ablaufen? In vielen Fällen mag das Sinn machen, aber als pauschales Konzept scheint mir das nicht sehr sinnvoll.

[Phoenix]

Zitat:

Zitat von jobo (Beitrag 1184494)

Wie soll sich bspw. ein intelligenter Client als Server verhalten, ohne selbst ein komplettes Datenbank-Replikat zu halten, was ja die Validierungsgrundlage ist?
Business Logik lebt doch im gesamten Datenkontext, idR. ein Mehrbenutzersystem, das nicht selten auch automatisiert Daten aus 3. System verarbeitet, wie und auch warum sollte auf einer solchen Basis eine Business Operation im Client ablaufen? In vielen Fällen mag das Sinn machen, aber als pauschales Konzept scheint mir das nicht sehr sinnvoll.

Niemand - auch kein intelligenter Client - braucht für einen atomaren Vorgang das gesamte Datenuniversum. Die Referenzielle Integrität betrifft in aller Regel nur unmittelbar zusammenhängende Datensätze. Die einzige Ausnahme wäre hier eine PK-Verletzung, weil ein Client etwas neu einfügt was schon da ist - was dann aber eher auf ein Usability-Problem hinweist, denn eine gute Software würde dem User vorher den schon existierenden Datensatz präsentieren und ihn nicht erneut eingeben lassen.

Heutzutage geht die Entwicklung sehr Stark in Richtung 'disconnected processing'. Ein gewisses Subset des Datenuniversums (meist Stammdaten + relevante Bewegungsdaten) exisitiert auf mehreren Devices, die ohne permanente Verbindung zum 'Backend' autark arbeiten - und sich dann in mehr oder weniger regelmäßigen Abständen synchronisieren. Ggf. laufen auch immer nur Teilbereiche einer Anwendung auf diese Art (z.B. Live-Auswertungen für das Management auf Tablets).

Das Problem ist hierbei, das solche Anforderungen nie von vorneherein auf der Spezifikation stehen, sondern erst später dazu kommen. Eine vernünftige Architektur sollte in der Lage sein, solche Szenarien relativ einfach zu ermöglichen - eine schlechte Architektur erschwert bzw. verhindert solche späteren Anpassungen.

[Sir Rufo]

@Phoenix :thumb:

Das gesamte Konstrukt ist Client/Server und nicht weil ich 2 Programme an 2 verschiedenen Orten habe.

Die GUI (Client) spricht mit dem Objekt und dem Manager (Server)
Der Manager (Client) spricht mit dem DatenLayer (Server)
Der DatenLayer (Client) spricht mit dem Betriebssystem um die Daten zu speichern (Server)

Der Clou an der Sache ist, dass der Client nicht wissen muss, wie die Verarbeitung im Server umgesetzt ist.
Jeder Server kann auch ein Client eines anderen Servers sein und ist dann eigentlich nur eine Leitstelle.
Dem Client davor ist das aber herzlich egal.

Und wenn alles in eine Anwendung gegossen wird (weil rein Single-User-Betrieb) dann ist das bei der Umsetzung immer noch C/S

[stahli]

Ich habe mir "Pattern für Enterprise Application-Architekturen" gekauft. Jetzt suche ich noch jemanden, die mir Abends immer vorlesen kann. :stupid:

Das Buch behandelt schon die richtigen Themen, ich bin jedoch noch bei der Einleitung. Also mal sehen, was die Zeit bringt.

Der Argumentation der geteilten Datenhaltung mag ich mich eher nicht anschließen. Sinnvoll ist das sicher dann, wenn regional unterschiedliche Daten interesssant sind, die irgendwann in einer zentralen Datenbasis zusammengeführt werden.
Wenn aber mehrere Firmenmitarbeiter mit exakt den gleichen Daten arbeiten müssen, dann würde ich das nicht zweckmäßig finden.

Aber danke für die Beteiligung.
Ich werde mal mit einem kleinen Testprojekt herum spielen...

[stahli]

Wer mag, schaue mal hier: http://youtu.be/8AxZTxn_OKE

[Sir Rufo]

Zitat:

Zitat von stahli (Beitrag 1185486)

Wer mag, schaue mal hier: http://youtu.be/8AxZTxn_OKE

Das Video ist privat ... lädst du uns alle auf ein Bier bei dir ein? ;)

[stahli]

Nee, bin schwer erkältet und kann momentan nicht einladen ;-)
Habs mal auf "nicht gelistet" gestellt...

[Bummi]

Hallo André,

wie verhält sich Dein Beispiel wenn mehrere Client gleichzeitig Änderungen vornehmen ...

[stahli]

Das gäbe natürlich Probleme. Die letzte Änderung würde sich durchsetzen.
Man kann/müsste sich hier überlegen, wie man eine Art abgespeckte Transaktionsverwaltung regeln könnte.
Zumindest müsste es eine Sperre für bestimmte Konflikte geben.

Im Moment wollte ich erst mal an die gezeigte Stelle kommen und das hat ganz gut funktioniert.
Die gesamte Projektlogik läuft im "SchoolManager" und die GUI im Client bekommt zur Designtime oder Laufzeit lediglich eine ObjektId und ggf. ObjektyProperty zugewiesen.

Eine 08/15-Datenbankanwendung soll mein Ansatz nicht ersetzen, ich möchte aber z.B. mein Turnierprojekt gern auf C/S umstellen und suche dafür Möglichkeiten.
Ich habe auch schon einen DB-Einsatz getestet aber das hat nicht wirklich funktioniert. Dafür die die Projektstruktur einfach zu komplex und variabel.
Daher will ich mit Objekten arbeiten. Auch die GUI soll die Daten in "Objekten" präsentieren, so dass der User die Spieler, Spiele, Felder usw. anfassen und verschieben kann.
Grids will ich vermeiden und deshalb ist auch DataBinding und DataSnap nichts passendes für mich.

Die Arbeitsweise, in den Client-Controls letztlich nur die PropertyNames einzutragen und den Rest dem Framework (sind hier letztlich nur 2 Units und die Controls) zu überlassen, hat sich für mich jedenfalls in meinem bisherigen Projekt schon sehr bewährt.

Die GUI-Controls fordern (wenn sie sich zeichnen müssen) eigenständig die benötigten Objekte bei ClientManager ab. Der ClientManager holt die Objekte vom Server. Falls von dort neuere Daten kommen, weist er das Control (bzw. dessen Controller) an, sich nochmal mit den neuen Daten zu zeichnen.

Natürlich fehlt da noch jede Menge (auch eine Eingabevalidierung), aber ich wollte Euch dennoch mal das erste Ergebnis zeigen und Eure Einschätzungen dazu hören.

[Sir Rufo]

Ich habe das Gefühl, dass du dich da etwas verrant hast.

Änderungen an Objekten sollten nur dann an den Server und dann an die Clients gesendet werden, wenn die Daten konsistent sind. Du schickst aber jede Teiländerung an die Clients, die ja noch während der Änderung in sich falsch sein kann. Somit bekommt ein Client Daten zu sehen, die unsinnig sein können.

Was DataBinding zwangsweise mit Grids zu schaffen hat, ist mir auch schleierhaft.

Nachvollziehen kann ich den Wunsch der Push-Funktion an alle Clients, wenn sich Daten geändert haben.

Nehmen wir die Schule als Beispiel:

Ein Schüler soll von Klasse A in Klasse B verlegt werden. Somit habe ich Änderungen an 3 Objekten.
Aber erst wenn alle 3 Objekte im Server abgelegt sind, dann haben alle Clients Zugriff auf konsistente Daten (Transaktion) und sollten dann informiert werden und nicht früher.

Sind die Daten bei Client A und B in Bearbeitung, dann ist es zudem sehr verwirrend für die Anwender, wenn sich wie durch Geisterhand die Daten verändern.
Dieses Kollisions-Management (gleichzeitige Änderung von mehreren Stellen am gleichen Datensatz) kann man unterschiedlich implementieren mit mehr oder weniger Aufwand:

• Letzte Änderung gewinnt (gesamtes Objekt)
• Objekt wird zur Bearbeitung exklusiv gesperrt
• Nur die Änderungen der Objekt-Felder werden übertragen (letzte Änderung gewinnt)
• Der Client bekommt die Fremd-Änderungen während der Bearbeitung beim Speichern angezeigt und kann darauf entsprechend reagieren