Konzeption mehrschichtiger Anwendungen

[DeddyH]

Ich bräuchte mal Eure Meinung. Ich möchte eine Anwendung schreiben, die folgendermaßen aufgebaut ist:
- Datenbank
- Zugriffsframework (OPF)
- Frontend

Das Frontend hat dabei keinen direkten Zugriff auf die DB, sondern nur über die Klassen des Frameworks. Das gibt es öfter und bedarf IMHO keiner weiteren Erläuterung. Ich frage mich lediglich, ob Folgendes sinnvoll ist:
Der Zugriff des Frameworks auf die DB erfolgt abfragetechnisch über Views und DML über SPs und zwar ausschließlich. Nirgends wird direkt auf die Tabellen zugegriffen.
Ich hatte das erst anders und musste dann feststellen, dass bei einer Umstrukturierung der DB das komplette OPF umgebaut werden musste. So wie beschrieben könnte es im Idealfall sein, dass lediglich auf DB-Seite Änderungen erfolgen müssen. Und im Nicht-Idealfall sind nur ein paar Parameter im OPF zu ergänzen/ändern/löschen.

Was meint Ihr, ist das sinnvoll so, oder habe ich da einen riesigen Denkfehler drin?

Danke fürs Lesen.

[edit] Zur Veranschaulichung der Frage die relevanten Stellen fett hervorgehoben [/edit]

[alzaimar]

Die Abgrenzung des Datenbankzugriffs entspricht meiner Vorgehensweise. Dabei verfolge ich zwei Prinzipien:
1. Aufgaben/Gewaltenteilung
2. Abstraktion

Dadurch, das Du nur 'virtuelle Tabellen' hast (nämlich deine View), sowie Operatoren darauf (SP), erlaubt es Dir, das zugrundeliegende DB-Konzept nachträglich noch zu verändern/erweitern. Ich habe z.B. eine ganze Reihe kleiner Prüf- und Loggingoperationen in den SP verbaut, die ich im laufenden Betrieb ein- bzw. wieder ausbauen kann.

Ich gehe beim MSSQL sogar soweit, 'Updateable Views' zu verwenden, womit das Prinzip der virtuellen Tabellen 100%ig umgesetzt ist.

Zum OPF: Ich würde eine 'Select'-Operation einbauen bzw. die Möglichkeit bieten, Queries direkt durchzureichen. Das ist bei der Darstellung von Listen, Grids etc. sehr hilfreich, auch wenn es den 3-Tier-Gedanken pervertiert. Die Entwicklungszeit wird hier jedoch drastisch reduziert. Wichtig ist nur, das eine 1:1 Beziehung zwischen Datarecord einer Query und Objekt (z.B. durch eine ID) gewährleistet ist, und das keinerlei Modifikationen direkt durchgeführt werden: Deine Business Logic ist ja im OPF, und die bekommt davon dann nichts mit.

Um Deine Frage zu beantworten: In meinen Augen ist diese Vorgehensweise entscheidend für eine robuste, wartbare und leicht veränderbare Lösung. Ich bin mittlerweile auch von 100% OPF weggekommen, weil man bei jeder Kundenanfrage ('Wir bräuchten noch die Schuhgröße des Kunden im Kundenstamm') die Mittelschicht aufgebohrt werden soll. Das muss sie aber eigentlich nur dann, wenn sich die Business Logic ändert. Für reine Nutzdaten ist das imho überflüssig (Prinzip der Gewaltenteilung).

Ich habe also hartkodierte Eigenschaften, die für die BL wichtig sind, und Nutzdaten als Key-Value-Paare (Dictionary) in meinen logischen Objekten. Die Keys der Nutzdaten entsprechen direkt dem Feldnamen meiner Objekt-View, sodaß sich Erweiterungen an dieser ('Schuhgröße') direkt und ohne Änderungen an der Mittelschicht im Frontend abgebildet werden können.

Gruß

[DeddyH]

Danke für Deine Antwort, ich liege also nicht so verkehrt :zwinker:. Da ich noch ziemlich am Anfang stehe, ist das ganze System noch nicht sonderlich ausgefuchst, aber Dein Post zeigt mir, dass ich wohl auf dem richtigen Weg bin :thumb:.

[RWarnecke]

Hallo Detlef,

vielleicht gibt Dir mein Thread noch mehr Informationen zu dem Thema, da ich gerade selber an so einem Konzept arbeite.

[DeddyH]

Hallo Rolf, den Thread hatte ich auch bereits mit Interesse verfolgt. Vielleicht können wir bei neuen Erkenntnissen ja querverlinken, dann haben wir beide etwas davon ;)

[RWarnecke]

Auf jeden Fall gerne.

[DeddyH]

Deal :thumb: