Deine Schlussfolgerung in Zukunft ALLE Datasets zur Laufzeit zu erzeugen ist aber auch nicht die Lösung.
Du verschenkst damit Entwicklungszeit und erhöhst die Menge des Sourcecodes.
(je mehr Sourcecode, umso mehr Fehlermöglichkeiten gibt es)
Das schöne ist bei meiner Vorgehensweise, das ich kaum Sourcecode habe und schon gar nicht wegen einer neuen Tabelle neuen Source ergänzen muss. Ich hatte mal vor ewigkeiten auf einer Entwicklerkonferenz dafür ein paar Sessions zum Thema
OOP gegeben und das Verfahren in den letzten 13 Jahren noch mal deutlich weiterentwickelt. Damals hatte ich durch einen Quelltextgenerator einfach zu jeder Tabelle in der
DB eine eigene
Unit erzeugt, in der dann eine von einer Basisklasse abgeleitete Klasse erzeugt wurde, die dann sämtliche Datenbankoperationen einheitlich abgewickelt hat und nebenbei auch noch dynamisch passende TWincontrols auf jeden beliebigen Container (TPanel, TScrollbox o.ä.) erzeugen konnte.
Erst auf der Ebene der Basisklasse habe ich dann die konkrete Implementation angesprochen, also ob das TQuery, TIBOQuery, TICQuery oder was auch immer war, solange es eine Dataset Ableitung war. Ich bekomme immer noch Tränen in den Augen, wenn ich sehe, wie viele Kundenprojekte zum Beispiel mal mit IBObjects realisiert wurden und wo man sich in ewige Abhängigkeit davon begeben hat. Wenn ich in einer
Unit nur den Konstrutor auf ein andere Klasse portieren muß dauert das ggf. nur wenige Minuten, wenn ich aber in 200 Datenmodulen 5000 Datasetableitungen mit 50000 TField Definitionen anpassen muß, dann sieht das schon ganz anders aus, insbesondere wenn es auf einmal gewisse TFieldklassen, -properties oder events gar nicht mehr pder mit anderer Implementation gibt.
Der Quelltextgenerator selbst hat danach dann auch noch (sofern nicht schon vorhanden) von dieser Klasse noch mal eine Ableitung erstellt, in der ich dann Methoden überschreiben konnte und völlig andere Implemetationen für komplexere Aufgaben umsetzen konnte.
Der Quelltextgenerator hat neben den Objektklassen auch noch automatisch diverse include files erzeugt, die ich dann im eigentlichen Projekt eingebaut habe. Da der meiste Sourcecode aus dem Quelltextgenerator erzeugt wurde war dieser per Definition fehlerfrei. Ob der dann das gemacht hat, was er machen sollte, lag am Sourcecode vom Quelltextgenerator, aber in einem großen Projekt mit ca. 800 Tabellen musste für die Kompatibilitätsschicht zwischen Firebird und IBM AS/400 iSeries (oder wie auch immer die Kiste jetzt heißt) nach einem Update auf der AS/400 Seite und der Umstellung von Delphi/400 auf
ODBC ziemlich viel geändert werden. Das wurde aber nur ein einer klasse exemplarisch manuell gemacht, bis es lief und dann der Quelltextgenerator angepasst, damit der die neuen Strukturen erzeugt. Die restlichen 799 Klasse dauerten danach weniger als eine Minute. Der Quelltextgenerator war übrigens eine ganz gruselige Implementation (TForm mit TMemo, TButton, einer TxDatabase, einer TxQuery) und einem endlosen OnClick Event, mit dem die gefundenen Metadaten aus der
DB in Delphi kompatiblen Quellcode umgewandelt wurde. Einige werden sich evtl noch dran erinnern ...
Das klassische
RAD Prinzip von Delphi ist zwar am Anfang sehr produktiv, aber bei Projekten, die mehrere Jahre auch in größeren Teams entwickelt werden sollen, kann das schon mal gewaltig nach hinten losgehen. Ob man sich mal vor Jahren zum Einsatz von IBObjects entschlossen hat, Orpheus oder Turbopower Krams eingebaut hat oder was auch immer vor einigen Jahren mal angesagt war: Die konkrete Implementation an zigtausend Stellen im eigenen Quellcode lässt sich meistens mit Mühe und Suchen/Ersetzen noch lösen, der ganze Kram in den DFMs ist dann aber oft schon mit dem ersten Öffnen der Formulare mit fehlender oder falschen Komponentenversion hoffnungslos vergurkt.
Ich habe im Laufe der Jahre diverse Softwarehäuser beraten, die oft auch meine Architektur übernommen haben und von denen habe ich viele Rückmeldungen, das dadurch die Fehler der Vergangenheit endlich hinter sich lassen konnten.
Mittlerweile läuft das bei mir ohne eigene Units pro Tabelle über eine im Laufe der Jahre entwickelte Basisklasse, bei der alle Information zu jeder Tabelle bei ersten Zugriff im Client gecacht werden. Für lesen und schreiben der Daten werde eigene SQLs automatisch erzeugt oder, sofern vorhanden, nach bestimmten Namenskonvention vorhandene SPs benutzt.
In meinem Modell ist die Datenbankstruktur Basis für alles andere, ich weiß aber auch, das viele das gerne andersherum lösen. Mein Vorteil ist, das meine Implementation mit völlig unterschiedlichen Datenbanken auch völlig unterschiedliche Anforderungen umsetzen kann, ich also für jeden Kunden individuell customizen kann. Ich glaub bei der Entwicklungszeit kann ich mit anderen Modellen sehr gut mithalten, die grundlegende Basis ist war nicht in 5 Tagen entwickelt, wenn man die dann aber stehen hat, geht es extrem fix.
Mehr Komponenten bedeutet nicht zwangsläufig weniger Quellcode, umgekehrt aber auch nicht. Der ganze Bereich der Programmierung wäre aber auch extrem langweilig, wenn es immer nur die "eine Lösung" geben würde.