Viele Formulare in einem Projekt

[Medium]

Eine Form sollte tunlichst NIE von irgendwem benutzt werden! Im Gegenteil: Die Forms bedienen sich selbst aus Feldern der unterliegenden Geschäftslogik. Sorum wird ein Schuh draus, alles andere ist ist eine wartende Wartungshölle oberster Güte.

Ähnlich bei DB-Controls: Ich finde die Dinger ziemlich böse. DB-Connections werden bitte ebenfalls zwischen Daten- und Geschäftslogik Schicht eingerichtet, und ein Formular darf sich dann freundlicherweise bei dieser Schnittstelle bedienen. Aber man pumpt ihm nichts von hinten rein!

Der Hinweis auf grobe Designfehler ist hier mehr als gerechtfertigt.

[jaenicke]

Ich selbst habe etwas ähnliches schon einmal umgesetzt:
Einen Pool, der die verschiedenen Module der Anwendung bereit stellt. Wenn ich jetzt das Formular XY anzeige, fragt dieses beim Laden die passende Businesslogik usw. von diesem Pool an. Ist sie bereits geladen, wird diese benutzt, andernfalls geladen.

Besonders interessant wurde das dadurch, dass alle Module nach dem Programmstart asynchron mit Abhängigkeiten und benutzerspezifischen Prioritäten geladen wurden. Diese Prioritäten werden statistisch aus den nach einem Programmstart zuerst angeklickten Modulen des Benutzers ermittelt, so dass statistisch meistens das am häufigsten nach dem Programmstart geladenen Modul auch bereits vorgeladen war.
Wenn nicht, wird es im Pool priorisiert, so dass es als nächstes geladen wird.

Auf diese Weise wurde aus einer Startzeit von ca. 2,5 Minuten eine Startzeit von 1-2 Sekunden, in aller Regel ohne eine spürbare Beeinträchtigung durch längere Ladezeiten während das Programm läuft. Der Splashscreen fiel dann auch weg, weil es schlicht nicht mehr viel zu laden gab.

Was ich damit sagen will:
Die Formulare sind doch in der Regel gar nicht das Problem, sondern die Logik dahinter. Die hat aber mit den Formularen selbst erst einmal nichts zu tun.

[scheufens]

Hi,
unser ERP besteht aus über 300 Formularen.
Wir erzeugen Formulare NIE automatisch!

Gruß
Bernd

[Furtbichler]

Delphi ist ein RAD-Tool (eigentlich: DAS RAD-Tool). RAD bedeutet in erster Linie 'Rapid'. Und da ist es logisch, das in diesem Kontext die Formulare sofort zur Verfügung stehen. Das könnte man auch mit Lazy-Load umsetzen, aber historisch hat Borcardero das nun mal anders gelöst. Schade eigentlich, aber egal.

Schön wäre so ein Pattern beim Erzeugen eines neuen Formulars: Statt

Delphi-Quellcode:

Unit MyForm;
interface
uses...
Type
  TMyForm...

Var
  MyForm : TMyForm;
...
// in der DPR
Application.CreateForm(MyForm, TMyForm);

einfach so (Lazy Load):

Delphi-Quellcode:

Unit MyForm;
interface
uses...
Type
  TMyForm...

Function MyForm : TMyForm;
implementation
Var
  _myForm : TMyForm:

Function MyForm : TMyForm;
begin
  if _myForm=Nil then Application.CreateForm(_myForm, TMForm);
  result := _myForm
End;

[jaenicke]

Der Vorteil wäre aber deutlich geringer als bei einer eigenen Umsetzung mit Hintergrundladen.

Dieser Automatismus ist ja nur für kleine Projekte da, damit es erst einmal funktioniert. Bei größeren Projekten macht man das doch ohnehin selbst in Abhängigkeit von den Anforderungen. Deshalb sehe ich gar keine Notwendigkeit das standardmäßig anders zu behandeln.

[Furtbichler]

Hmm. Stimmt. In meinen Projekten habe ich auch nur wenige ständig instantiierte Formulare (die, die sehr komplex sind). Der Rest wird grundsätzlich erzeugt, ausgeführt und wieder freigegeben.