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!
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.
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.