Datenbankanwendung und Klassen - sinnvoll?

[stahli]

Stimmt beides.


1) Binding

Die GUI-Controls sollen m.E. nicht die gesamte Datenschicht und schon gar nichts von der Businesslogik kennen.

Ein Edit soll nur wissen, dass es die Eigenschaft Name eines Objektes mit der ID 12345 darstellen und ggf. ändern soll.
Oder die Eigenschaft Caption des Objektes mit dem Namen "Form1".
Oder die Eigenschaft "Kennzeichen" eines Objektes mit dem Namen KFZ1.

Das Edit muss dann einen Manager beauftragen, das gewünschte Objekt zu finden und muss dann nachsehen, ob dieses die gewünschte Eigenschaft besitzt. Ggf. muss der Wert der Eigenschaft noch in einen anderen Datentyp umgewandelt werden.

Der Manager seinerseits kann nach bestimmten Regeln in der Datenschicht nach dem Objekt suchen oder z.B. auch per FindComponent innerhalb der GUI. Dem Edit ist es somit egal, ob es an die Datenschicht gebunden ist oder an das Formularcaption.

Im Grunde ist es ähnlich wie ein DBEdit an ein Tabellenfeld zu binden - nur eben viel flexibler.

Die GUI-Schicht selbst kennt dabei weder die Datenschicht noch umgekehrt.


2) GUI-Logik

Die GUI darf und muss natürlich selbst auch Logik erhalten aber das sollte sich wirklich konkret NUR auf die sichtbaren Aspekte beziehen.
Ein MaskEdit ist ein schönes Beispiel. Es akzeptiert selbst schon nicht, wenn ungültige Zeichen z.B. für ein Datum eingegeben werden.
Man könnte ähnliche Prüfungen auch im Formular durchführen, solange man dafür keine Analysen in der Datenschicht benötigt.
Wenn ich z.B. die Kinder für Personen erfasse und die Geburtsdaten prüfe (dass die Kinder nicht vor den Eltern geboren sind usw.) dann muss solch eine Prüfung in der Datenschicht erfolgen. Diese könnte eine Schnittstelle TPerson.KinderSindValide unterstützen.
ButtonOk.Enabled könnte an Person("#Aktuell").KinderSindValide gebunden werden. Dann kann ich die Person nur speichern, wenn die Datenschicht das erlaubt, ohne dass die GUI wissen muss worum es geht.

Auf ungültige Zeichen prüfen kann man natürlich auch schon direkt in der GUI, wobei ich mich frage, ob das immer Vorteile bringt.

[p80286]

Zitat von stahli:

Wenn ich z.B. die Kinder für Personen erfasse und die Geburtsdaten prüfe (dass die Kinder nicht vor den Eltern geboren sind usw.) dann muss solch eine Prüfung in der Datenschicht erfolgen. Diese könnte eine Schnittstelle TPerson.KinderSindValide unterstützen.

Interessantes Beispiel.
Wie ist der Ablauf?

• Abruf des Elterndatensatzes
• Zuweisung der Info "hatKind(er)"
• Erfassung der Kinderinformation u.u. mit angepasster Oberfläche

oder vllt. so

• Erfassung der Personendaten
• Suche der Eltern
• Zuweisung der Info "ist Kind"+ID_Eltern)

Wobei meiner Meinung nach die erste Möglichkeit Benutzerorientiert und die zweite Datenbankorientiert ist. Optimal wäre es den Ersten Ablauf zu zeigen und den zweiten in der "Datenwirklichkeit" zu tun.
Und so etwas kannst Du nur erreichen wenn das UI nicht mit der Datenschicht fix verdrahtet ist.

Zitat:

Auf ungültige Zeichen prüfen kann man natürlich auch schon direkt in der GUI, wobei ich mich frage, ob das immer Vorteile bringt

Wie üblich, es kommt darauf an, ist ja hier oft genug diskutiert worden (copy und paste ....)

Gruß
K-H

[stahli]

Welcher Weg für das Eltern-Kinder-Beispiel der beste ist muss man im Projektkontext sehen.

Wenn Eltern und Kinder von der selben Klasse TPerson sind ist das schon etwas anderes als wenn man einer Person eine Liste von Autos zuordnet.

Das ist der Knackpunkt:

Zitat:

Und so etwas kannst Du nur erreichen wenn das UI nicht mit der Datenschicht fix verdrahtet ist.

Unter dieser Voraussetzung hat man im Grunde alle Freiheiten.

In der Datenschicht kann ich meine Personen definieren, die eine Liste von anderen Personen erhalten kann (die Kinder) und eine Liste von Autos.

Optimal wäre es, wenn ich für jede Klasse ein "Bearbeitungsfoirmular zuweise", das projektweit gilt. Wenn ich irgendwo eine Person sehe kann ich das zugewiesene Bearbeitungsformular TFormPerson durch Doppelklick erzeugen und öffnen. Ebenso ein Formular für Auto-Objekte.

Die GUI-Controls werden automatisch an die passenden Objekteigenschaften gebunden, ohne dass man dazu etwas programmieren muss.

Der OKButton.Enabled wird an das FormarObjekt.IsValide im Personenformular oder FormularObjekt.IsValide im Autoformular gebunden. "FormularObjekt" ist das Objekt, für das das Formular geöffnet wurde. Das alles kann ohne Quelltext realisiert werden.

Ob man nun die Kinder in einer Tabelle erfasst oder in einer Listbox sammelt und jeweils wieder über ein eigenes Formular bearbeiten lässt, ist dann eigentlich zweitrangig.


Ein Problem, das ich in meinem Framework auch noch nicht bearbeitet habe ist das Verwerfen von Änderungen.
Wenn ich z.B. ein Kind hinzufüge muss das Kind-Objekt in der Datenschicht erzeugt werden. Wenn ich das Bearbeitungsformular aber schließen und das Kind verwefen will oder muss, muss das Objekt aus der Datenschicht auch wieder entfernt werden.
Gleiches gilt, wenn ich den Namen einer Person ändere und die Änderung wieder verwerfen will (ESC). Es muss dafür so eine Art Transaktion geben, die es ermöglicht, Objekte und Objekteigenschaften vorläufig zu ändern und später die Änderung fest zu machen oder zu verwerfen.

Diese Transaktionsverwaltung sollte nicht einer Datenbank überlassen werden da (zumindest in meinem Framework) die Objekte ja auch ohne Datenbankanbindung erzeugt und persistiert werden können.


Den beste Lösung für das Eltern-Kind-Beispiel müsste man sich noch überlegen. Man sollte sich daran orientieren, was der Anwender am ehesten wünscht.
Egal, ob man die Kinder in einer Tabelle oder in einer Listbox erfassen lässt, die Objekteigenschaften und die Validitätsprüfungen wären jeweis die gleichen.
Im Falle eines Kinder-Bearbeitungsformulars würde der OK-Button im Fehlerfall deaktiviert und ich könnte das Kind nicht schließen, im Falle einer Kinder-Tabelle wäre der entsprechende Datensatz rot markiert und ich könnte meine Person nicht schließen.


Wichtig ist vor allem, dass man im Formular nichts prüft was die Daten betrifft. Solche Zugriffe sollten immer auf definierte Schnittstellen begrenzt und darüber hinaus abstrahiert werden.

Das Formuar sollte auch auf keinen Fall die Klassen TPerson und TAuto kennen. Damit wäre eine lose Bindung schon dahin.


Man könnte die Datenschicht eigentlich fast als Komponente betrachten.
Das Projekt nutzt z.B. eine TEdit anhand derer Schnittstellen, ohne sich über dessen Innenleben Gedanken zu machen.
Das Projekt setzt die Eigenschaft Text eines Edit und liest sie wieder aus. Es kann prüfen, ob das Edit sichtbar und aktiviert ist oder ob es den Fokus hat.
Genau so kann und sollte die Datenschicht betrachtet werden. Es gibt Schnittstellen, an die sich die GUI binden kann - alles andere ist Privatsache. Natürlich ist die Zugriffsmöglichkeit auf die einzelnen Detaildaten komplexer als auf einfache Propertys einer Komponente, weshalb ein Manager für die Vermittlung zwischen GUI und Datenschicht erforderlich ist. Der kennt einige Schnittstellen der GUI (und kann dort über Datenänderungen informieren) und kennt die Struktur der Datenschicht (und kann so die benötigten Objekte verwalten und heraus geben). Die Objekte selbst kennen auch wiederum den Manager und können dort z.B. den Besitzer eines bestimmten Autos erfragen - genau wie die GUI.


Seit der erweiterten RTTI von D2010 lassen sich solche Dinge wunderbar umsetzen (schaffe ich ja sogar ).
M.E. ist das ein völlig neues Arbeiten.


Früher gab es mal ECO und Bold wo m.E. ähnliches versucht wurde. Das wurde dann aber leider nicht richtig ausgebaut.

[vagtler]

Zitat von stahli:

[...] Früher gab es mal ECO und Bold wo m.E. ähnliches versucht wurde. Das wurde dann aber leider nicht richtig ausgebaut.

Leicht OT: An ECO wird wohl noch immer mehr oder weniger aktiv gearbeitet: http://www.new.capableobjects.com/downloads/ - allerdings als reines .NET-Framework.

[Furtbichler]

Lustig: Das aktuelle Projekt arbeitet nur mit Views zur Ansicht und Operationen zur Manipulation der Objekte. Die ursprünglichen Programmierer haben doch tatsächlich ein eigenes ORM geschrieben (in C#), weil sie wohl meinten, sie seien die Größten. Nun denn.

Daten werden so gut wie nie direkt verändert, sonder immer über stored procedures. Also ist der Sinn eines ORM nur der, viel Code zu produzieren.

Was benötigen wir hier also? Na ja, eigentlich nur etwas zum Binden der Daten an visuelle Darstellung, und da täte es auch einfach nur ein TDataSource. Die Operationen selber werden dann mit Businessoperationsbjekten umgesetzt, die kann man Testen und fertig. Die einzelnen Formulare, die die BO darstellen, haben dann natürlich ein Viewmodel. So kann man BO und VM wunderbar testen.

Es muß nicht immer ORM sein, es kommt *immer* auf die Problemstellung an. Im aktuellen Fall ist die Businesslogik in den Stored Procedures untergebracht. Muss man nicht machen, kann man aber. Ergo ist ein ORM überflüssig.

Wenn aber nicht, wenn also die ganze Logik in der Anwendung abgebildet wird, dann geht es ohne ordentliches ORM nicht.

[süden]

Hallo,

danke für die rege Anteilname, aber ...
... die letzten Einträge haben wenig mit meiner (Anfänger)Frage zu tun.

Vielleicht wäre es das Thema wert, für die Profis ein eigenens Thema aufzumachen? Dort könnten dann die konreten Details besprochen werden.
Ich könnte dann mitlesen.

Mein Wunsch wäre hier eine Grundsatzdiskussion. Zur allgemeinen Vorgehensweise, wie ein Projekt aufgebaut werden sollte.
Mit Tipps zu funktionierenden Dingen.

Oder Ihr macht weiter und ich mache einen Neuen auf.

Nichts für Ungut ...

[süden]

PS: Ich bin nicht beleidigt, ich fühle mich nur ausgegrenzt und überfordert.

[Sir Rufo]

Zitat von süden:

PS: Ich bin nicht beleidigt, ich fühle mich nur ausgegrenzt und überfordert.

Das geht allen so, die vier Räder an eine Platte schrauben und das Teil sich bewegt, und dann fragen, wie man jetzt einen konkurrenzfägen Formel-1 Rennwagen baut.

Soll heißen, es ist nicht trivial

[stahli]

Ich kann Deine Überforderung durchaus verstehen.
Deshalb finde ich es ja schade, dass Delphi noch keinen Königsweg für eine andere Art des Arbeitens mit liefert.

Dieser "Königsweg" würde wiederum mehrere Bereiche umfassen, die zusammenspielen müssen um ein einfaches, übersichtliches und flexibles Gesamtkonzept zu erhalten.

Insgesamt ist das schon recht aufwendig und es gibt unterschiedliche Lösungsansätze.
Schön wäre es, wenn es ein fertiges Gesamtpaket mit Demoprojekten gäbe, so dass die Programmierer einen schnellen Zugang finden.

Leider ist das noch nicht gegeben und die Diskussionen sind eher theoretischer Natur bzw. beziehen sich auf unterschiedliche Teilaspekte des Ganzen.


Das Problem hast Du ja in Deinem Eröffnungsbeitrag angesprochen.
Für deren Lösung gibt es unterschiedliche Ansätze. Der eine schwört auf dieses der andere auf jenes.

Der einheitliche Tenor aller Lösungen sollte sein: Trennung von GUI und Businesslogik+Daten.
In einer OnClick-Behandlung sollte man also NIEMALS etwas berechnen oder ändern, das die Projektdaten betrifft (egal ob diese in einer Datenbank oder in Objekten verwaltet werden). Insofern verführt Delphi sehr dazu, ungünstig zu programmieren.
Zum Lernen und für kleine Demoprojekte ist das zwar in Ordnung und bequem, aber wenn Projekte wachsen wird es schnell sehr unübersichtlich und fehleranfällig.

GUI und BL zu trennen macht etwas mehr Aufwand (wenn man kein Framework nutzt das diesen Aufwand wieder minimiert), ist aber langfristig gesehen für größere und wichtige Projekte der bessere Weg.

Versuche einfach mal, auf direkte Datenzugriffe aus dem Formularquelltext zu verzichten. Der Aha-Effekt wird sich sicher einstellen.


Was insgesamt der beste Weg dafür ist musst Du selbst heraus finden. Einen Königsweg gibt es eben leider (noch?) nicht.

[Hansa]

Zitat von süden:

ich fühle mich nur ausgegrenzt und überfordert.

Kann ich verstehen, allerdings ausgegrenzt, das stimmt jetzt wirklich nicht. Die "Experten" schiessen aber wirklich öfters weit über das Ziel hinaus. Du weisst, was ein Record ist ? Ja, das sind eben Daten, die irgendwo gespeichert werden. Wenn ich jetzt noch da in der Logik die Behandlungsweise dieser Daten reinpacke, dann ist das ein Objekt/Klasse.

Ne, das wird wieder zu theoretisch. Am besten ist immer noch das TP 5.5 Handbuch. Das stammt zwar aus ca. 1990, aber weil keiner damals wusste, was OOP eigentlich ist oder wozu das gut ist, ist es einfach gehalten.

http://edn.embarcadero.com/article/i..._OOP_Guide.pdf