Datenbankanwendung und Klassen - sinnvoll?

[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

[süden]

Danke, Ihr seit so lieb - ich bin wieder dabei.

Bisher habe ich genau das gemacht: Klick -> a + b = c ....
und es hat funktinoniert (!?)

Das Ding ist gewachsen und Anwender melden sich, könnte man ...
... klar, warum nicht ...
und dann häng ich da, bekomme meinen Code nicht mehr gebacken + 10-20 mal so viel Zeit wie geplant (und bezahlt) ... Ihr kennt das sicher.

1) Also - Klassendesign lernen
2) Keine BL im Form
3) Date trennen? Wie? die kommen ja im Form an !!! Und es ist so einfach die da zu lassen!

[Hansa]

Zitat von süden:

3) Date trennen? Wie? die kommen ja im Form an !!!

Welches Date ? Das ist kein deutsches Wort und auf englisch ist 'Date' in Deutsch ein Datum (=Tages-Zeitraum), aber es kann auch die Einzahl von Daten sein. . Wer soll denn das und noch mit nicht mal richtigem Denglisch noch beantworten ? Ich sage nur : Kauderwelsch.

[süden]

Tschuldigung, ich wollte DATEN schreiben. Nicht Date = Datum.

[Hansa]

Du kannst also doch Deutsch ? Für Rest gilt : TP 5.5

[stahli]

So pauschal kann man schlecht sagen, was die beste Herangehensweise ist.

Es ist auch davon abhängig, die Dein bisheriges Projekt aufgebaut ist (eine Datenbank und welche - welche Datenbankkomponenten (DBEdit?)), wie die Daten bisher im Formular eingebunden werden, wie Berechnungen usw erfolgen.

Grundsätzlich könnte man sagen, dass die gesamte BL ohne ein Formular funktionieren sollte.
Dann könnte man sagen: BL.BerechneAlleKundenAlter oder BL.SucheAlleKundenMit('A') oder BL.Kunde(1).AddiereZuKonto(1000).

Vom Formular aus ruft man dann nur noch die definierten Schnittstellen auf.
Das Formular muss die Klasse TKunde und TKonto dann nicht kennen. Es muss nur wissen, wo es die Daten zur Darstellung her bekommt, aber nichts von Berechnungsformeln usw.

"BL" könnte eine Klasse sein, oder ein eigenes Projekt in einer Projektgruppe oder einfach ein DataModule (wobei das dann keine richtige Trennung von der GUI mehr ist) oder sogar eine DLL.

Die Frage ist dann wieder, wie man der GUI beibringt, welche Daten sie anzeigen soll.
Das sollte möglichst einfach und flexibel sein und genau klemmt derzeit noch die Delphi-Säge.

[Furtbichler]

Zitat von stahli:

"BL" könnte eine Klasse sein, oder ein eigenes Projekt in einer Projektgruppe oder einfach ein DataModule (wobei das dann keine richtige Trennung von der GUI mehr ist) oder sogar eine DLL.

Der Business-Layer ist idealerweise eigentlich keine Klasse, sondern eine Schicht: Wenn Du alle Klassen deines Projekts vertikal so anordnest, das die Abhängigkeiten einer Klasse ('Uses Liste') immer nur nach oben zeigen, dann kannst Du diese Hierarchie in einzelne Schichten unterteilen.

Ganz oben ist die UI, also Formulare, Komponenten usw.

Ganz unten die Datenmodule (wenn Du welche hast). Oberhalb der Datenzugriffschicht (also dort, wo mit der Datenbank kommuniziert wird) liegt normalerweise der Business Layer, der Daten von der Datenschicht nimmt, Umformungen der Daten vornimmt (nach Aufforderung von oben) und diese wieder an die Datenschicht zum speichern übergibt.

Die Befehle zur Datenmanipulation kommen aus der UI oder besser noch: Aus einer Schicht dazwischen, dem Viewmodel. Dieses Viewmodel stellt eine 'Fassade' dar (nicht mit dem Pattern gleichen Namens verwechseln), welche die Daten und Operationen der BL-Schicht so maskiert, das die UI diese ohne großartige eigene Logik darstellen kann.

Die Sache mit dem Viewmodel ist nicht sehr weit verbreitet und bei kleineren Projekten auch nicht wirklich nötig, denn es ist schon eine ganze Menge Mehrarbeit.