Datenbankanwendung und Klassen - sinnvoll?

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