Carla - Mo 30.11.09 11:25
Titel: Reportprogramm isolieren

---

Hallo,

in einem großen Programm ist ein umfangreicher Reportgenerator vorhanden. Dieser wird von mehreren Stellen im Programm, mit relativ wenig Parametern aufgerufen. Da ich das Programm aus Gründen der besseren Wartbarkeit modularisieren will, bin ich am Überlegen welche Lösung die praktischste ist. Der Reportgenerator soll in eine eigenständige Applikation ausgelagert werden.
Das Tool soll Druckaufträge entgegennehmen und ausführen. (Beispiel für Aufrufparameter: Liste=63 Kunde=12 Rechnung=1234)

dll scheidet Aufgrund der Probleme mit Laufzeit.bpl aus.
Es bleiben zwei Varianten.
Realisierung als Exe-File mit Kommandozeilenaufruf oder Druckwarteschlange.
Realisierung als Comserver.


Comserver ist klar. Als Out-of-process-Server wird dieser beim ersten Aufruf vom OS gestartet und das

Beenden automatisch verwaltet.

Bei einer Exe muss eine SingleInstance erzeugt werden und die Aufrufparameter in einer Warteschlange abgelegt werden.


Gibt es noch weitere Lösungsansätze? Welchen Ansatz würdet ihr bevorzugen ?

Mit Gruß
Carla

Moderiert von Narses: Überflüssige Zeilenumbrüche/Leerzeilen entfernt.

JDF - Mo 30.11.09 13:08

---

Hallo Carla!

nach meinen gegenwärtigen Erfahrungen (12 Jahre Multitier) würde ich Dir eine COM-DLL empfehlen.
Durch die Einbettung in COM+ kannst Du eine einzelne Prozess-Umgebung für die DLL generieren,
ohne eine einzige Programmzeile ändern zu müssen.

Wäre es nicht ratsam, über die Probleme mit Laufzeit-BPL's zu reden und mit einer guten Lösung
den Weg zur DLL wieder zu öffnen?

Gruß
Jürgen

Carla - Mo 30.11.09 13:49

---

JDF hat folgendes geschrieben:

Wäre es nicht ratsam, über die Probleme mit Laufzeit-BPL's zu reden und mit einer guten Lösung den Weg zur DLL wieder zu öffnen?

BPL müssen gegen die gleiche Compilerversion gelinkt werden. Ein Drittanwender ist praktisch nicht in der Lage auf seinen Rechner eine eigene dll für das System zu compilieren, wenn er nicht den exakt gleichen Versionsstand der BPL verwenden kann.
Die Registrierung von Klassen durch einige Komponenten, schließt die gleichzeitige Verwendung in anderen
BPL/Dll aus.
Com und Exe sind die einzigen Möglichkeiten die Programme sauber zu trennen und auf Drittrechnern compilierbar zu halten.
BPL halte ich für einen Designfehler in Delphi. Darüber zu reden, heißt ja ein anderes Modulkonzept
einzuführen. Wäre nicht schlecht (z.B. Assembly)

Moderiert von Narses: Zitat repariert.

JDF - Mo 30.11.09 15:00

---

Zitat:

BPL halte ich für einen Designfehler in Delphi

Halte BPL's auch für eine gut gemeinte aber unglückliche Lösung für die die Zeit abgelaufen ist.
Wenn Drittanwender eigene Compilerläufe ausführen müssen, dann ist die BPL aus dem Rennen.
Drittanwender können eine COM-EXE leichter handhaben als eine COM-DLL im COM+(Registrierung + Konfiguration).

Ein Zugriff über das COM-Interface öffnet auch die Grenzen der Programmiersprache (Java, C, VB, C#...).

Carla - Mo 30.11.09 15:26

---

JDF hat folgendes geschrieben:

Ein Zugriff über das COM-Interface öffnet auch die Grenzen der Programmiersprache (Java, C, VB, C#...).

OK ich bin überzeugt.
Ich werde eine COM-Exe verwenden.
Sollte unter Windows7 64 bit wohl noch funktionieren? (Im 32 bit Subsystem)

Moderiert von Narses: Zitat repariert.