Vor ca 15 Jahren hatte ich mal für einen Kunden basierend auf seiner Firebird Datenbank Struktur
ein Quellcodegenerator geschrieben, der so ein ähnliches Projekt mit ca 800 Formularen
automatisch erzeugt hat (es gab auch auf der Ekon damals Sessions zu dem Thema von mir).
Idee war das es zu jeder der 800 Tabellen Tabelle eine
pas und eine
dfm Datei erzeugt werdent,
diese automatisch mit allen Feldern Grids, Edit Controls o.ä. nach einer zentralen Routine
zusammengestellt wurden.
Außerdem wurde dann automatisch zu jedem automatisch erstellten Form ein vererbtes Formular
erzeugt wurde, in dem man dann für die komplexeren Masken seine eigenen Ergänzungen und
Anpassungen machen konnte, ohne das die beim nächsten Durchlauf des Quelltextgenerators
gleich wieder übergebügelt werden.
Alle Formulare wurden dann zur Stammdatenbearbeitung in TMenu* eingetragen und man hatte mit relativ
wenig Aufwand für eine sehr komplexe Datenbank schon mal ein voll funktionsfähiges Grundgerüst, um
sämtliche Daten in der
GUI bearbeiten zu können und trotzdem nicht bei jeder Datenbankänderung
hunderte Formulare einzeln anpassen zu müssen ....
Ergebnis war bei 800 Tabellen aber dann ein
dpr Projekt mit ca 3200 Dateien (je 2 dfms und 2
pas pro
Tabelle), was über den Quelltextgenerator relativ einfach zu handlen war und wir konnten uns auf
die komplexen Formulare konzentrieren. Außerdem natürlich noch ein paar weitere Units für die
Basistechnik.
Grund für die Architektur waren in dem Kundenprojekt (weltweit tätiges Unternehmen mit ca
2000 Mitarbeiter), das die daraus entstehende Kunden/Auftrags/Produkt Verwaltung in
Teilbereichen sehr komplex waren und 2 Mitarbeiter nur damit beschäftigt waren, das
Datenmodell anhand von Grundregeln an das anzupassen, was die Fachabteilung in dem
jeweiligen Bereich vorgegeben hat. Beide hatten nicht eine einzige Pascal/Delphi Quellcode
jemals gesehen, konnten aber wenn sie die angeforderten Strukturen der Fachabteilung
verstanden hatten, mit simplen create table befehlen die Strukturen in der Datenbank
anlegen und dann on demand oder im Nachtdurchlauf dann eh eine neue exe mit der Fachabteilung
antesten und deren Feedback zeitnah auf das Datenmodell anpassen oder komplexe wünsche
an die Delphi Entwickler weitergeben, die sich dann mit den Anforderungen im vererbten Formular
auseinander setzen konnten. Das war ausgesprochen effektiv, weil nicht ein Fachmann aus der
Fachabteilung mit dem erforderlichen Prozesswissen einen Programmierer, der von den Prozessen
keine Ahnung hat und oft auch nicht wirklich in der Kommunikation den Fachleuten gewachsen ist
und andauernd "Ja, hab ich verstanden" sagt, obwohl er keine Ahnung hat, wovon der andere redet.
Die "Middleware" Abteilung zwischen Anwendern und Programmierern hat ganz sicher sehr viel
Zeit gespart.
Wenn man aber das fertige Projekt sieht und klassische Delphi Programmierung gewöhnt ist
bei der man jede zeile code selber geschrieben hat und jedes Form selber erzeugt hat, und den
Quelltextgenerator nicht kennt und auch nicht selber anpassen kann, wird man
mit diesem Projekt komplett überfordert sein und sich höchstens wundern, warum alle
objektnamen, quelltextformatierungen immer so einheitlich aussehen.
Unsere aktuelle brp Architektur geht dabei noch einen Schritt weiter und erzeugt alles, was damals
in
dfm/
pas dateien ging, automatisch zur Laufzeit und daher kann eine exe völlig unterschiedliche
DBs bedienen, weil ähnlich wie beim browser/webserver bei uns die exe alle informationen aus der
Firebird
db zieht und dort auch alle Prozessfunktionen mit Bezug zu Tabellen als SP abgelegt sind.
Fazit: Anzahl der Forms ist nicht generell ein Problem, wenn es aber (wie ich das extrem oft
bei Kunden gesehen hab) jedes mal individuell erzeugte Formulare sind, und Datenmodule im Projekt
sind, bei der die Komponenten darauf selbst den Platz auf einem 4k Monitor sprengen, dann zitiere
ich mal einen Kollegen von früher (Carlos Ebers, leider auch in diesem Sommer gestorben) auf die
Frage
"Was würdest du mit dem Projekt machen"
Seine Antwort: fdisk
(für nicht ganz so alte Hasen: das ist der dos befehl gewesen, um die partition zu löschen und neu
zu erstellen)