Sw-Architektur Drei-Schicht Anwendung

[lowmax_5]

Hallo,

ich habe mal eine grundlegende Frage zum Aufbau einer datenbankbasierten Anwendung, die aus drei Schichten bestehen soll. (Darstellung, Anwendungslogik, Datenbankschicht). Ziel ist es z.B. die Darstellungsschicht gegen eine andere Technologie zu tauschen z.B. VCL gegen Html-Darstellung, ohne dass die beiden Anderen Schichten dafür verändert werden müssen.

Wie verhält es sich dann mit der Weiterleitung von Eregnissen, wie z.B. dem Doppelklick, oder rechte Maustaste, etc. ein ein Button, wenn die verwendete dDrstellungstechnik dieses nicht unterstützt?

Wie ist z.B. ein AfterScroll-Event auf der Datenbankschicht zu realisiseren um dieses an die Darstellungsschicht weiterzuleiten?

Wie seid Ihr dieses Thema angegangen? Ist es schlichtweg notwendig, diese Ereignisse nicht zu verwenden. Welche Lösung bietet sich hier an?

lowmax

[p80286]

Sehr amateurhaft gedacht:
Wenn Du auf einer Oberfläche einen Namen eingibst der in einer Datenbank gesucht werden soll,
dann benötigst Du Daten (den Namen) und ein auslösendes Event. Dies kann das Verlassen des Namenfeldes sein, das anklicken eines Buttons, daß Drücken einer Tastenkombination ....

als pseudocode

Delphi-Quellcode:

function FühreMeineFunktionAus(eingabedaten):string;
begin
  result:='';
  if isnumeric(Eingabedaten) then
   result:=DB_Abfrage_Name(eingabedaten);
end;

procedure myevent;
begin
  ZeigeDatenan(FühreMeineFunktionAus(meinedaten));
end;

Sinnvoll wäre es natürlich, die einzelnen Schichten in unterschiedlichen Units zu definieren, damit auch vom Arbeitsablauf her die "Schichtung" klar wird.

Gruß
K-H

[mkinzler]

Das ist aber kein Multi-Tier sonderm MVC (Model View Controller).

[Furtbichler]

In der Mittelschicht werden die Funktionen/Operationen der einzelnen logischen Datenobjekte ausgeführt.

z.B. "LadeKundendaten (in Suchkriterien, out KundenDaten)".

Das ausfüllen der Suchkriterien übernimmt das Frontend, wo MVC, MVVM, ABC, oder DUDELIDU als Pattern eingesetzt werden können. Wichtig ist hier, das das Frontend nur für das Anzeigen und Ausfüllen der Datenobjekte zuständig ist und die Operationen von der Mittelschicht ausführen lässt.

SOA geht auch in die Richtung, nur das hier "die Mittelschicht" aus den einzelnen Diensten besteht.

[Daniela.S]

Ich hatte einen ähnlichen Anwendungsfall - eine bestehende, recht aufwendige Anwendung sollte sowohl als VCL Anwendung, als auch im Internet zur Verfügung stehen. Zum Glück ist die Anwendung selbst von der Architektur her gut aufgebaut und beinhaltet keinerlei Logik im VCL-Layer. Logik und D

Im Grunde habe ich dann anstatt der VCL einen kleinen Layer gebastelt, der die benötigten Eigenschaften der VCL-Objekte im Speicher nachbildet und ansonsten keine Funktionen zur Verfügung stellt. Darüber liegt dann eine Ebene mit einem Datasnap Server, der mit diesem Layer kommuniziert. Auf der anderen Seite stehen alle Funktionen und Ergebnisse als REST Service anhand von JSON Objekten zur Verfügung.

Auf der Webseite erledigt dann HTML/JavaScript (asp.net mit Prism geht auch) die Darstellung und das Weiterleiten an den Datasnap Server. Ging an sich recht flott und eine extrem komplexe Anwendung konnte (weil in ihrer Architektur eben gut abstrahiert) innerhalb weniger Tage über das Internet bedient werden.

Ereignisse sind natürlich schwieriger einzubinden. Wir haben versucht diese so weit als möglich zu vermeiden. Bei DataSnap gibt es aber die Möglichkeit eines Callbacks. Das wäre sicher auch eine Möglichkeit...

lg,
Daniela

[Phoenix]

Zitat:

Zitat von lowmax_5 (Beitrag 1208084)

die aus drei Schichten bestehen soll. (Darstellung, Anwendungslogik, Datenbankschicht). Ziel ist es z.B. die Darstellungsschicht gegen eine andere Technologie zu tauschen z.B. VCL gegen Html-Darstellung, ohne dass die beiden Anderen Schichten dafür verändert werden müssen.

Wie verhält es sich dann mit der Weiterleitung von Eregnissen, wie z.B. dem Doppelklick, oder rechte Maustaste, etc. ein ein Button, wenn die verwendete dDrstellungstechnik dieses nicht unterstützt?

Gar nicht. Das ist ja gerade der Sinn und Zweck der von einander getrennten und voneinander abstrahierten Schichten in einer N-Schichten Architektur.

Ein vom User ausgeslöstes Event (z.B. Der Doppelklick, oder ein Touch-Ereignis, oder eine Braille-Eingabe zum Scrollen etc.) ist eine Aktion auf der gerade von diesem User verwendeten Darstellung. Hat also weder in der Anwendungslogik noch in der Datenbankschicht irgend etwas zu suchen.

Ein Scrolling hat lediglich dafür zu sorgen, dass die Darstellungsschicht der Anwendungsschicht sagt: Geb mir mal ab dem x-ten User Datensatz die nächsten Y Stück, sortiert nach A,B und C absteigend (klassisches Pageing).

Welche Events dafür jetzt notwendig sind, sind damit rein auf die Darstellungsschicht begrenzt.

Das ist insbesondere wichtig wenn Du, wie Du schreibst, von einer klassischen Desktop-Anwendung ins Web willst. HTTP als das Grundprotokoll im Web ist Stateless, das heisst bei jedem einzelnen Request vom Webbrowser gegen Deine Anwendung kann (bzw. besser sollte) Deine Anwendung auf dem Server keinerlei Ahnung von dem haben (müssen), was der User vorher gemacht hat. Alles andere Wäre eine grobe Verletzung des Protokolls und sorgt vor allem zu netten Fehlermöglichkeiten.

Man stelle sich nur mal vor, der User macht ein neues Browser-Tab im Zustand X auf, tippelt dort was rein, macht inzwischen im alten Tab Y und Z (der Server meint der User wäre bei Z), und dann wechselt er den Tab und schicht das modifizierte X zurück. Wenn Deine Anwendung damit nicht zurecht kommt, gute Nacht.

[QuickAndDirty]

Zitat:

Zitat von lowmax_5 (Beitrag 1208084)

Hallo,

ich habe mal eine grundlegende Frage zum Aufbau einer datenbankbasierten Anwendung, die aus drei Schichten bestehen soll. (Darstellung, Anwendungslogik, Datenbankschicht). Ziel ist es z.B. die Darstellungsschicht gegen eine andere Technologie zu tauschen z.B. VCL gegen Html-Darstellung, ohne dass die beiden Anderen Schichten dafür verändert werden müssen.

Es ist schon mal gut wenn sich Leute VORHER solche Gedanken machen!

Zitat:

Zitat von lowmax_5 (Beitrag 1208084)

Wie verhält es sich dann mit der Weiterleitung von Eregnissen, wie z.B. dem Doppelklick, oder rechte Maustaste, etc. ein ein Button, wenn die verwendete dDrstellungstechnik dieses nicht unterstützt?
Wie ist z.B. ein AfterScroll-Event auf der Datenbankschicht zu realisiseren um dieses an die Darstellungsschicht weiterzuleiten?

Sowas gibt es nicht schicht übergreifend. Was ist denn, wenn deine Oberfläche gar kein Scrollen kennt? Was wenn dein UI rein akustisch funktioniert und vielleicht maximal ein paar Wähltöne kennt? Um eine echte Wiederverwendbarkeit der Geschäftslogik zu gewährleisten muss man stark abstrahieren.

Zitat:

Zitat von lowmax_5 (Beitrag 1208084)

Wie seid Ihr dieses Thema angegangen? Ist es schlichtweg notwendig, diese Ereignisse nicht zu verwenden. Welche Lösung bietet sich hier an?

Ich verwende in letzter Zeit öfter ein MVP Pattern (Model View Presenter), aber es sollte auch MVVM oder MVC usw. funktionieren. Der "Richtigste" Ansatz ist aus heutiger Sicht natürlich SOA (Service Oriented Architecture), aber auch SOA muss in UI, Logik und Persistenz Dienste aufgeteilt werde und SOA ist recht aufwendig, dafür spielt es seinen Großen Vorteil nur aus wenn sich die Anforderungen an die Software schnell ändern.

Es gibt verschiedene Möglichkeiten MVP umzusetzen je nach dem was man sich verspricht kann man mehr oder weniger Code in den Presenter packen. Ich bevorzuge einen Presenter der einfach nur UI und Logik miteinander verheiratet und sonnst nichts tut. Man kann auch im Nachhinein in ein bestehendes "RAD"-Projekt neuen Code nach MVP sauber einbinden, Nicht die ganze Anwendung muss sich an so ein Pattern halten.

Die Persistenzschicht ist so eine eigene Geschichte. Viele wollen hier keine Austauschbarkeit, dann muss man das nicht so sehr berücksichtigen.
Je mehr Flexibilität gewünscht wird desto abstrakter sollte der Zugriff sein.
-nur MSSQL Server = Eine eigene und fast unveränderte Ableitung einer beliebigen DB-Zugriffs-bibliothek auf TDataset Basis.
-mehrere SQL Server = So wie oben, aber der Zugriff sollte abstrakter sein so das DB spezifische SQLs nicht teil der Geschäftslogik sind
-verschiedenste medien/Dateiformate/Cloud/Services/Streams/noSQL-DB/SQL-Server = Hoher Abstraktionsgrad notwenig.
Dann gibt es noch die Möglichkeit sich den Scheiß mit der Persistenz vom Hals zu schaffen, in dem man auf ORM-Frameworks setzt.