Datenbankanwendung und Klassen - sinnvoll?

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

[stahli]

Genau diese Komplexität ist der Grund, warum ich ein entsprechendes RundumSorglosPaket im Delphi vermisse.

Die meisten Programmierer hätten doch sicher gern ein Framework, das einem die entsprechenden notwenigen Arbeitsschritte abnimmt ohne dass man sich mit den Details herumschlagen muss. (Ich zumindest auf jeden Fall.)

Es ist doch ineffektiv, wenn jeder sein Framework selbst erfindet... Und Anfänger würden direkt zu einem guten Projektaufbau hin geführt.

[Hansa]

Tja, @sueden : siehst ja selber, dass Einführung in OOP so nicht geht.

[stahli]

Man redet über Anwesende ja nicht in der dritten Person
aber ich denke, süden versteht schon die OOP an sich - das Problem ist wohl eher die Stufe drüber, also die Strukturierung der Projektebenen und deren Verbindung.

[Hansa]

Welche dritte Person ? Ich rate auch Dir oder Furtbichler : Handbuch für TB 5.5 OOP. Da steht alles drin, was wichtig ist. Da wird nämlich einiges viel zu kompliziert angegangen.