Viele Formulare in einem Projekt

[dr. jack1]

Hallo zusammen,

habe mal eine allgemeine Frage:

Mein Projekt umfasst derzeit ca. 36 Formulare. Ist das zwecks Geschwindigkeit und evtl. Stabilität überhaupt noch sinnvoll oder sollte man es auf einzelne Teilprogramme auslagern und diese dann ggf. aufrufen? Aktuell habe ich zwar keine Probleme, nur das Starten dauert natürlich etwas länger.
Da das Projekt ehr noch wächst, ist es für mich sicherer es im Vorfeld schon zu wissen...


Danke und viele Grüße,

Jack

[Furtbichler]

Ich würde nur ein einziges Formular im Hauptprogramm erstellen lassen, alle anderen 'on demand', d.h. wenn man das Formular benötigt.

[danielmagin]

genau so macht man es. alle anderen werden dann nur on demand erzeugt. :-D

[Der schöne Günther]

Kommt wohl auch immer darauf an, was man für eine Zielgruppe hat. Ich habe mir lieber einen billigen Splashscreen zusammengezimmert und erzeuge und richte alle Formulare (z.B. Overlays und Popup-Dialoge) direkt beim Start ein.

Die Ladezeit für die Anwendung ist bei mir ziemlich egal, aber wenn ich im Betrieb eine halbe Sekunde für ein Monsterformular sparen kann nehme ich das dankend an.

[himitsu]

OK, in Zeiten wo selber billige FertigPCs mit 16 GB RAM ausgestattet sind...


Aber man stelle sich mal vor alle würden so arbeiten...

[DeddyH]

Ich versuche da stets, eine gute Balance zu halten. Fenster, die eigentlich immer wieder gebraucht werden, erzeuge ich automatisch, (modale) Eingabefenster zur Laufzeit. Damit erspart man sich auch ggf. das Löschen alter Daten. Pauschal zu sagen "alles sofort erzeugen" oder "alles erst zur Laufzeit" halte ich persönlich für blödsinnig, es kommt halt immer auf den Einzelfall an, da beides Vor- und Nachteile hat (wer hätte das gedacht? *g*).

[Bernhard Geyer]

Zitat:

Zitat von Der schöne Günther (Beitrag 1230957)

Kommt wohl auch immer darauf an, was man für eine Zielgruppe hat. Ich habe mir lieber einen billigen Splashscreen zusammengezimmert und erzeuge und richte alle Formulare (z.B. Overlays und Popup-Dialoge) direkt beim Start ein.

Die Ladezeit für die Anwendung ist bei mir ziemlich egal, aber wenn ich im Betrieb eine halbe Sekunde für ein Monsterformular sparen kann nehme ich das dankend an.

Wie wäre es die (Monster)formular bei der ersten verwendung zu initalisieren und dann nur noch wieder zu verwenden. Das wäre m. E. maximal ein Kompromiss.

Zitat:

Zitat von himitsu (Beitrag 1230960)

OK, in Zeiten wo selber billige FertigPCs mit 16 GB RAM ausgestattet sind...

Hat Windows immer noch Ressourcenbegrenzungen im Bereich Handels und GDI-Ressourcen.
Und was bringen dir 16 GB wenn du dein programm immer noch als 32-Bit Exe bereit stellst ... :-)

[himitsu]

8 Programme mit 2 GB (oder gar mit 3 GB) machen das dennoch schnell voll. :zwinker:

Im Prinzip wie es DeddyH schon sagte.
Nur da, wo es "unbedingt" nötig ist, daß vorher laden.

Wobei man es auch teilweise machen kann, nur einige Dinge cached (das, was wirklich langsam ist) und das "langsame" Formular dennoch erst dann erstellt, wenn es benötigt wird.


Eventuell auch mal überlegen, ob das Programm wirklich 400 Formulare benötigt und man da nicht besser erstmal was Anderes optimiert.

[sx2008]

Zitat:

Zitat von dr. jack1 (Beitrag 1230905)

... oder sollte man es auf einzelne Teilprogramme auslagern und diese dann ggf. aufrufen?

Nur wenn sich die Aufgaben der potentiellen Teilprogramme ohne Überlappungen trennen lassen.
Ein Beispiel wäre eine Hauptanwendung und ein Backupprogramm dass die Datenbank und lokalen Einstellungen sichert.
Oder das Hauptprogramm soll Dateien per FTP hochladen.
Hier könnte man eine weitere Anwendung beilegen, die sich nur um den Datentransfer kümmert und vom Hauptprogramm aufgerufen wird.

Delphi bietet leider recht schwache Möglichkeiten eine Anwendung zu unterteilen ("Partitionierung").
Der Versuch einige Formulare in DLLs auszulagern scheitert regelmässig an folgenden Gründen:
1.) Anwendung + DLLs benötigt mehr Speicher in RAM und auf Disk als eine monolitische Anwendung
2.) Probleme bei Updates weil Anwendung und DLLs zusammenpassen müssen
3.) aufwändigere und langsamere Entwicklung weil Schnittstellen zw. Anwendung und DLLs entwickelt werden müssen und sich nur mit höherem Aufwand ändern lassen
4.) erhöhter Aufwand beim Debuggen
5.) auch mit Delphi Packages (=DLL mit objektorientierter Schnittstelle) kommt regelmässig Stress auf weil man dann VCL-Packages benutzen muss. VCL-Packages muss man global für den ganzen Rechner installieren.
Tut man dies nicht erreicht man nichts anderes dass man den Rechner mit BPL-Dateien vollmüllt und man mindestens doppelt soviel Diskspeicher benötigt als wenn alles in einer EXE wäre.

[Mathematiker]

Hallo,
ich habe selbst ein Projekt laufen, dass im Moment 100 verschiedene Formulare für verschiedene Berechnungen und grafische Darstellungen nutzt.
Mit dem Tip von jaenicke

Delphi-Quellcode:

procedure ShowForm(const AFormClass: TFormClass);
var
  MyForm: TForm;
begin
    MyForm := AFormClass.Create(nil);
  try
    MyForm.ShowModal;
  finally
    MyForm.Free;
  end;
end;
...
   showform(TFirgendetwas);

werden die modalen Formulare in dem Moment gerufen, wo sie gebraucht werden. Es funktioniert absolut problemlos und vor allem geschieht der Aufruf sehr schnell.
Die Startzeit der Anwendung ist minimal, der Speicher wird nicht übermäßig belastet, was will man mehr. Natürlich geht das so nur mit modalen Fenstern.

Beste Grüße
Mathematiker

[himitsu]

Zitat:

VCL-Packages muss man global für den ganzen Rechner installieren.

Nein.

Einfach ins Programmverzeichnis legen reicht vollkommen.
Dann könnten sogar mehrere Programme unterschiedliche VCL-Versionen nutzen.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1230989)

Dann könnten sogar mehrere Programme unterschiedliche VCL-Versionen nutzen.

Können Sie auch so seit die Packages (seit D3?) mit Versionnummern (VCL30.bpl, VCL40.bpl, ...) versehen sind.

Ein (für uns) Hauptgrund gegen Packages ist aber das man in den mitgelieferten Packages keine selbst eingepflegten Patches rein bekommt.

[himitsu]

Ich meinte vorallem innerhalb einer Hauptversion.

Mit Updates, Hotfixes, Fixpacks usw. kommt man da nicht so schön zurecht.

[mkinzler]

Grundsätzlich funktioniert dass auch bei nichtmodalen Fenstern. Man muss diese nur so konfigurieren, dass diese bei Schliessen freigegeben werden

[Bjoerk]

Zitat:

Zitat von dr. jack1 (Beitrag 1230905)

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:

Zitat von Bjoerk (Beitrag 1231023)

Zitat:

Zitat von dr. jack1 (Beitrag 1230905)

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 :roll:

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 :cyclops::cyclops::cyclops: da alle DB-Controls fortlaufend aktualisiert werden müssen.

[Bjoerk]

Zitat:

Zitat von Bjoerk (Beitrag 1231023)

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

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;

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