Programm modularisieren

[gabneo]

Hi,
hatte da noch eine Idee, wie sieht es denn damit aus:
Du führst Shellexecutes aus und übergibst der Exe parameter mit...damit würdest du keine WM_Copydata senden müssen und hättest aber das einfache Handling von exe-files

greez
gabneo

[hanspeter]

Zitat von gabneo:

Hi,
hatte da noch eine Idee, wie sieht es denn damit aus:
Du führst Shellexecutes aus und übergibst der Exe parameter mit...damit würdest du keine WM_Copydata senden müssen und hättest aber das einfache Handling von exe-files

greez
gabneo

Dann wird aber jedesmal eine neue Instanz des Programmes angelegt und ich möchte, wenn einml gestartet, das Programm bis zum Ende des Mainprogrammes laufen lassen.

Gruß
Peter

[hanspeter]

Um das Thema mal abzuschließen.
Ich habe in der vergangenen Woche alle Verfahren ausprobiert und für mich ergibt sich nachfolgendes Ergebnis.

Wenn es keine technologische Notwendigkeit (Plugin-System o.ä.) gibt, lohnt sich eine Modularisierung mit Delphi nicht.
Ein sauberes OOP-Design vorausgesetzt ist eine monolithische Lösung besser.
Begründung:
Der Speicherbedarf ist bei Modularisierung immer signifikant höher.
Es entsteht zusätzlicher Aufwand zur Verwaltung der Module.
Die BPL Lösung ist nur verwendbar, wenn ein Versionskontrollsystem und/oder eine automatische Installationskontrolle
vorhanden ist. (z.B. über Internet prüfen welche Module jünger sind und diese herunter laden.)
Das hängt damit zusammen, das Delphi beinahe willkürlich ältere Module mit compiliert und diese dann updatet werden müssen.

Dll Lösung.
Benötigt trotzdem Laufzeit - bpl und der Debugger ist beim Test von dll schlichtweg eine Zumutung.

Framwork Hydra als Plugin- System.
Funktioniert gut. Hier auch Probleme beim modulübergreifenden Testen.
Potentiell aber gefährlich. Das Modul läuft wohl im gleichen Prozessraum.
Enthält irgendein Modul eine Delphi Komponente, welche sich mit Registerclass registriert, dann muss diese Komponente
als Laufzeit-BPL bereitgestellt werden.
Erst zur Laufzeit kommt ein Fehler, wenn in irgendeiner Konstellation zwei Module
mit der gleichen Klasse aktiviert werden.
Zur Entwicklungszeit merkt man diesen Fehler nicht. Im Gegenteil- Das Programm kann wochenlang laufen.
Erst wenn eine bestimmte Konstellation aktiviert wird, kommt es zum Fehler.

ActiveX und Com-Server scheiden aus, wenn W98 nicht als System ausgeschlossen werden kann. Der Overhead und die Notwendigkeit zur Registrierung verursachen zusätzlichen Aufwand.
Der Test gestaltet sich sehr schwierig.

Das vorgestellte Beispiel mit einer Exe-Datei und Interprocesskommunikation über TCP/IP oder Named Pipes ist interessant,
wenn sich der Datenaustausch auf ein Minimum reduziert und der Vorgang problemlos serialisierbar ist.
Ich habe im konkreten Fall die gesamte Reporterzeugung in ein eigenes Modul ausgelagert.
Das Modul initialisiert sich beim Start aus der Ini-File des Hauptprogramms.
Im laufenden Betrieb ist dann nur noch die Nummer des gewünschten Reports und die Anzahl zu übertragen.
Die Information wird auf einen Stack abgelegt und dann sequentiell abgearbeitet.
Die Vorgehensweise hat den Vorteil, dass ich den Reportgenerator mit eigener Oberfläche starten kann.

Fazit
Modularisierung nur zur Programmstrukturierung lohnt sich erst in Net und bringt erst hier echte Vorteile.
In Win32 macht es Sinn den zusätzlichen Aufwand für Modulverwaltung und Versionskontrolle lieber in das OOP Design
zu stecken und das Programm selber monolithisch zu lassen.
Die Zeit welche man dadurch spart, das man statt 10 mbyte nur ein 2 mbyte Modul übertragen muss, wird ohnehin durch die
notwendige Versionskontrolle und das Nachladen weiterer Module egalisiert.

Gruß
Peter