Ahoi Elvis,
Wo Du (bedingt) Recht hast (Datenmodule kapseln nichts), hast Du (bedingt) Recht. Natürlich ist das nicht die reine Lehre, aber die öffentlichen Komponenten sollen doch auch öffentlich sein und dienen der Interoperabilität mit den Formularen. Und die Geschäftslogik in Form der Ereignisse ist gekapselt. Der Designer bietet uns leider nicht die Möglichkeit, private Komponenten zu plazieren. Aber wenn das ginge, wäre das natürlich nett.
Das Datenmodule hingegen per se "furchtbare Biester" sind, "die Entwicklern vormachen, sie würden ihre App strukturieren, wobei sie in Wirklichkeit worst-case-Pasta erzeugen", sehe ich nicht. Es gilt immer: Wer's nicht kann, soll die Finger von den 'Biestern' lassen. Man muss sie auch bändigen können...
Bei den Möglichkeiten bzw. den Unmöglichkeiten, mit einer
RAD automatisch gute Software zu erstellen, gebe ich Dir aber unbedingt Recht.
Aber wir sprechen von zwei paar Schuhen: Bei Systemen, die die, sagen wir 100.000 Codezeilen-Grenze durchbrechen, wird man sich hüten, mit Klick-und-Gut-Datenmodulen zu arbeiten. Das wäre ja wirklich Selbstmord. Da braucht es dann auch 90% der Komponenten nicht mehr und man sollte Delphi bzw.
RAD (=Prototyping) wirklich nur für die
GUI verwenden, wobei dann auch die
GUI nicht mehr statisch sein dürfte und auch dann Delphi (und jede andere
IDE) derzeit nicht in der Lage sein dürfte, die dynamischen Formulare zu unterstützen.
Bei Projekten zwischen 5.000 und 100.000 (nur Hausnummern) bietet
RAD eine wirklich brauchbare Möglichkeit, Projekte in vertretbarer Zeit zu vernünftigen Preisen anzubieten, die dann (entsprechende Dispziplin vorausgesetzt) auch wartbar sind. Alles, was darüber hinaus geht, geht damit nicht mehr.
Bevor ich diesen Exkurs abschließe, möchte ich noch darauf hinweisen, das
RAD imho eher RAP heißen sollte, also nicht
Rapid
Application
Development, sondern einfach
Rapid
Prototyping. Und dann verbietet es sich ja, sich eine ordendliche Anwendung zusammen zu klicken...