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ß