Viele Formulare in einem Projekt

[Bjoerk]

Zitat von dr. jack1:

Da das Projekt ehr noch wächst, ist es für mich sicherer es im Vorfeld schon zu wissen...

Würde sagen, kommt drauf an, was die Forms in ihren FormCreates so alles erzeugen und ob eine Form von mehreren Forms verwendet wird. Die Forms lokal bzw. unitglobal zu erzeugen kann schnell ziemlich unübersichtlich werden und auch zu Fehlern führen (Form1.Form101.List <> Form2.Form101.List <> AForm101.List).

[musicman56]

Zitat von Bjoerk:

Zitat von dr. jack1:

Da das Projekt ehr noch wächst, ist es für mich sicherer es im Vorfeld schon zu wissen...

Würde sagen, kommt drauf an, was die Forms in ihren FormCreates so alles erzeugen und ob eine Form von mehreren Forms verwendet wird. Die Forms lokal bzw. unitglobal zu erzeugen kann schnell ziemlich unübersichtlich werden und auch zu Fehlern führen (Form1.Form101.List <> Form2.Form101.List <> AForm101.List).

ich würde sagen, das ist dann aber eher ein Design-Problem

Die Vor- und Nachteile der Formularerzeugung zur Laufzeit habt ihr ja schon durch. Auf die meiner Meinung nach wichtigste Frage seid ihr jedoch noch nicht eingegangen, bzw. hat der TE gar nicht hingewiesen: wird eine Datenbank verwendet, d.h. werden in den Formularen Datenbankinhalte angezeigt? In diesem Fall ist das Erzeugen aller Formulare da alle DB-Controls fortlaufend aktualisiert werden müssen.

[Bjoerk]

Zitat von Bjoerk:

ich würde sagen, das ist dann aber eher ein Design-Problem

Aha. Was soll denn daran bitte ein Designproblem sein, wenn eine Form von mehreren anderen benutzt wird? Am Beispiel der DB hast du es doch selbst schön erläutert, daß nämlich in dem Fall diese Forms global sein müssen?

[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;