ich liebäugel schon lange mit Klassen (nicht lachen bitte), und habe ein schlechtes Gewissen, weil ich noch keine selbst gebaut habe.
Du musst Dich nicht schämen, das ist nix schlimmes, aber Du solltest daran arbeiten...
Das Thema interessiert mich auch sehr. Im Grunde geht es um einen Themankomplex:
- Trennung Daten+Geschäftslogik von der
GUI
- lose und einfache Verbindung der beiden Schichten
- effektive und einfache Definition der Klassen
- effektive und einfache Einbindung von Datenbanken (ORM)
Ich finde es schade, dass das Thema bisher so vernachlässigt wird.
Es gibt zwar verschiedene Lösungen für einzelne Teilaspekte aber m.E. nichts was alles abdeckt.
Im Grunde geht es daraum:
- Ich will sehr einfach Klassen definieren. Bestenfalls über Metadaten (also Auflistung der gewünschten Probpertys) oder sogar grafisch. Die grundlegenden Eigenschaften und Fähigkeiten sollen automatisch vorhanden sein.
- Ich will den Klassen die Geschäftslogik (Methoden) hinzufügen können.
- Ein Framework soll sich darum kümmern, die Objekte zu erzeugen, zu verwalten und auf Anfrage bereit zu stellen (Kunde(12345)).
- Die Datenspeicherung soll ebenfalls automatisch und möglichst flexibel erfolgen.
- Die
GUI soll keinerlei Kenntnis der Daten und Geschäftslogik haben. Sie soll lediglich wissen, welche Daten sie darstellen soll (Namen eines Kunden oder Kennzeichen eines KFZ) und wo sie diese abrufen kann. Die
GUI sollte also weitgehend ohne Quelltext auskommen. Wenn ein KFZ-Objekt in seiner Eigenschaft HatTÜV false liefert könnte ein OK-Schalter deaktiviert werden, ohne dass die
GUI selbst weiß warum.
Dafür muss die Datenschicht natürlich Schnittstellen bereit stellen, an die die
GUI gebunden werden kann.
Grundsätzlich würde ich komßplexere Projekte eher mit Klassen aufbauen, da die Projekte dann aus meiner Sicht flexibler zu warten und besser zu verstehen sind.
Andererseits ist es natürlich auch möglich, die gesamte Funktionalität in Datenbanken zu packen und dann in der
GUI nur noch dumme
DB-Controls zu verbauen.
Letztlich ist das Geschmacksache und von den eigenen Fähigkeiten abhängig (bzw. davon was man als Entwickler besser kann).
Wichtig ist auf jeden Fall, die Geschäftslogik nicht in der
GUI umzusetzen und beides miteinander zu vermischen. Dann hat man schon mal die besten Voraussetzungen für eine vernünftige Projektstruktur.
Ich würde mir wünschen, dass Delphi diesbezüglich besser unterstützen würde.
Hier mal einige Links, die in diese Bereiche gehen:
http://www.delphipraxis.net/164573-d...nd-hoeher.html
http://www.delphipraxis.net/161102-k...onisieren.html
http://www.delphipraxis.net/172249-d...iskussion.html
http://www.delphipraxis.net/165090-g...nkprojekt.html
http://www.delphipraxis.net/164270-k...zu-mormot.html
http://www.delphipraxis.net/176478-m...realitaet.html
Und natürlich:
[Werbeblock]
http://www.delphipraxis.net/173360-s...framework.html
[/Werbeblock]