Hallo,
ich muss ein größeres Programm modularisieren.
Das Programm wurde bis her als 12Mbyte große Exe ausgeliefert.

Die Modularisierung soll erfolgen, um das Programm bei Änderungen fehlerunabhängiger zu machen.
Zur Modularisierung werden ja bei Delphi gemeinhin BPL verwendet.
Hier hatten sich aber einige Probleme ergeben, da alle neu compilierten Bpl mit ausgeliefert werden müssen und
Delphi hier manchmal willkürlich etwas eigenmächtig ist.
Eine weitere Alternative sind dll mit den bekannten Nachteilen unter Delphi.

Ich bin jetzt am Überlegen, ob es sinnvoll ist, ein Projekt auf der Basis von Exe-Files zu modularisieren.
Es gibt ein Hauptprogramm und hier mehrere Menüpunkte. z.B. Kundendaten oder Rechnungsdaten.
So ein Modul benötigt zum Start nur die Kundennummer oder bei Rechnungsdaten die Rechnungsnummer.

Das aufrufende Programm übergibt die Information als Kommandozeilenparameter, eine Pipe oder ähnlich.
Das gestartete Programm teilt seine Handleadresse in der Registry (oder über Pipe) dem Hauptprogramm mit.

Was spräche denn gegen eine derartige Art der Modularisierung?

Eine weitere Überlegung ist das Programm dann mit dem kommenden BDS 2007 unter Net neu zu kompilieren.
Ich vermute mal, dass CG dann statt BPL Assemblys erzeugt. Es wird wohl eine große Delphi.dll benötigt, diese dann
wohl für alle Delphi-Assemblys?
Schrittweise wäre dann auf dieser Basis die Umstellung des Projektes auf Net denkbar.

Welchen weg würdet Ihr bevorzugen?

Für einen tip dankbar,

Carla

Bei mir im Geschäft wurde eine Modularisierung durch aufteilen in verschiedene Exe-Files
gemacht. Hat Vorteile, aber auch Nachteile.
Man muss halt alles irgendwie hin und her übergeben.

Aber im ganzen sind wir eigentlich zufrieden.

Wenn du überlegst in .NET zu machen und der Aufwand vertretbar ist, dann
würde ich das machen. Allerdings bezweifel ich, dass eine 12MB große Exe so
einfach nach .NET zu portieren ist.

arj hat folgendes geschrieben:

Bei mir im Geschäft wurde eine Modularisierung durch aufteilen in verschiedene Exe-Files gemacht. Hat Vorteile, aber auch Nachteile. Man muss halt alles irgendwie hin und her übergeben.

Was waren denn die Nachteile?
Die Exe wird mit Parametern vom Hauptprogramm gestartet und muss eigentlich keine Daten zurückgeben.
Bei diesen geringen Datentransfer könnte man natürlich auch über Dll nachdenken?
Mit Exe hätte auch den Vorteil, das mann einzelne Module als getrenntes Programm zur Verfügung stellen könnte.
Wird z.B. die Mitgliedsnummer nicht als Aufrufparameter übergeben, dann fragt das Modul diese ab.
Mit Gruß
Carla

Das übertragen großer Datenmengen zwischen den einzelnen Teilen war ein Problem.
Kam aber zum Glück selten vor.

Vorteil ist ganz klar, dass die Programme einzeln gestartet werden können.
Da freuen sich unsere Anwender immer drüber

Wenn es sein muss, würde ich auch eine Aufteilung in mehrere Exe's vorziehen. Ich arbeite hier an einem grossen Projekt, bei dem relativ fühzeitig entschieden worden ist, zu modularisieren und wir haben uns damals für BPLs entschieden. Wir haben daher eine Vielzahl von Modulen, die zur Laufzeit mit LoadPackage und UnloadPackage geladen und entladen werden. Eine bessere Zuverlässigkeit oder Fehlertoleranz ist dadurch nach meiner Erfahrung aber nicht gegeben, im Gegenteil - da man sich zusätzliche Komplexität aufhalst, gibt es mehr Fehlerquellen. Wenn in einem Modul eine schwerwiegender Fehler (z.B. eine Zugriffsverletzung) auftaucht, reisst es aller Wahrscheinlichkeit immer noch das gesamte Programm in den Abgrund. Der einzige Vorteil ist meiner Meinung nach ein psychologischer: Wenn ein Fehler in einem Modul auftaucht, kann man dem Kunden nur dieses Modul ausliefern statt die ganze Software. Daher weiss der Kunde, dass sich an dem Rest nichts ändert und hat weniger Angst, dass ein Update irgendwas anderes kaputtmacht.
Mir wäre mittlerweise eine einzige Exe deutlich lieber, obwohl diese bei unserem Projekt wahrscheinlich 30 MB oder noch größer wäre. Diese Umstellung wäre aber zuviel Aufwand und wahrscheinlich auch gegenüber unseren Kunden nicht durchsetzbar.

Mehrere Exes hätten den Vorteil, dass sie wirklich fehlertoreranter wären - der Absturz eines Moduls würde die restlichen nicht jucken. Nachteile hat dieser Ansatz aber auch: Separate Exes brauchen mehr RAM und starten langsamer als eine einzige. Wenn eure Software datenbankbasiert ist (nehme ich nach deinem Posting an), braucht jedes Modul seine eigene Datenbankverbindung.

Vielversprechender als eine Modularisierung auf Executable-Basis ist meiner Meinung nach eine gute Architektur: wir haben unsere Software in den letzten Jahren in ein vernünftiges objektorientierte Struktur gebracht. Wir haben für alle Entitäten, die es in unserem Programm gibt (Kunden, Produkte, Aufträge usw.) eigene Klassen eingeführt, die die Geschäftslogik implementieren und dafür verantwortlich sind, sich selbst in die DB zu schreiben bzw. daraus zu lesen. Die Formulare benutzen nur noch diese Klassen und führen selbst keine Datenbankoperationen mehr durch. Dadurch ist Geschäftlogik und Datenbank-Code zentralisiert statt über das ganze Programm verteilt und es ist leichter, Änderungen zu machen oder Fehler zu finden.

Stefan

Stefan.Buchholtz hat folgendes geschrieben:

Wenn es sein muss, würde ich auch eine Aufteilung in mehrere Exe's vorziehen. Stefan

Ja das ist das Problem.
Der Code ist historisch gewachsen und geht so in Richtung von etwas mehr als 1 Mio. Quellzeilen.
Im Moment ist es so, das sich Änderungen im Programmcode an Stellen auswirken, wo wir es nicht vermutet haben und dann
kommt in einen Modul beim Kunden ein Fehler. Das Modul hatten wir gar nicht angefasst.
Das Programm setzt auf dem Firebird-Server aus. Daten zum Hauptprogramm werden nicht übermittelt.
Beim Aufruf wird der Datenbankstring und die Referenznummer als Parameter übergeben.
Was mir an der Exe - Lösung gefällt ist die Möglichkeit funktionsfähige Teile der Gesamtlösung als Einzelprogramm
auszuführen.
Meine Frage nach dem Pferdefuss dieser Lösung kommt daher, das ich eine Exe-Lösung in der Praxis noch nicht gesehen habe.

Ein Redesign wäre sicherlich angebracht.
Wenn ich das anfange, möchte ich dann aber eher in Richtung Net gehen.
Deshalb auch die Überlegung mit BDS 2007 eine Zwischenlösung zu schaffen.

Carla hat folgendes geschrieben:

Ja das ist das Problem. Der Code ist historisch gewachsen und geht so in Richtung von etwas mehr als 1 Mio. Quellzeilen. Im Moment ist es so, das sich Änderungen im Programmcode an Stellen auswirken, wo wir es nicht vermutet haben und dann kommt in einen Modul beim Kunden ein Fehler. Das Modul hatten wir gar nicht angefasst.

Unser Projekt bewegt sich in etwa der gleichen Größenordnung und diese Probleme hatten wir vor ein paar Jahren auch - mit einen komplett via BPLs modularisierten Programm. Die helfen dir wie gesagt in dieser Hinsicht gar nichts.

Carla hat folgendes geschrieben:

Das Programm setzt auf dem Firebird-Server aus. Daten zum Hauptprogramm werden nicht übermittelt. Beim Aufruf wird der Datenbankstring und die Referenznummer als Parameter übergeben. Was mir an der Exe - Lösung gefällt ist die Möglichkeit funktionsfähige Teile der Gesamtlösung als Einzelprogramm auszuführen. Meine Frage nach dem Pferdefuss dieser Lösung kommt daher, das ich eine Exe-Lösung in der Praxis noch nicht gesehen habe.

Damit habe ich selbst auch keine Erfahrungen.. Im Moment sehe ich auch keinen Haken ausser erhöhter Resourcenbedarf sowohl auf dem Datenbank-Server als auch auf den Clients.
Was du dann noch entscheiden musst: Module mit Laufzeit-Packages oder ohne? Ohne Laufzeit-Packages schleppt jedes Modul die VCL, etwaige Zusatzkomponenten und was ihr selbst noch an Klassen und Bibliotheksfunktionen gebaut habt, selbst mit sich rum, was den Speicherbedarf erhöht. Mit Laufzeit-Packages wird er Speicherbedarf der Module geringer, aber wenn ihr eigene Komponenten oder Klassen habt, die von mehreren Modulen verwendet werden, müsst ihr selbst darauf achten, keine inkompatiblen Änderungen an diesen zu machen oder im Bedarfsfall alle abhängigen Module neu zu kompilieren und auszuliefern. Ein möglicher Kompromiss wäre auch, nur von Delphi mitgelieferte Packages als Laufzeit-Packages zu verwenden.
Ein Build-System in hier von Vorteil, wir haben uns selbst eins gebaut.

Carla hat folgendes geschrieben:

Ein Redesign wäre sicherlich angebracht. Wenn ich das anfange, möchte ich dann aber eher in Richtung Net gehen. Deshalb auch die Überlegung mit BDS 2007 eine Zwischenlösung zu schaffen.

Mit .NET habe ich mich bis jetzt kaum beschäftigt, da kann ich dir leider nichts zu sagen. Von der VCL.NET habe ich allerdings bislang wenig gutes gehört - da ist denke ich auf jeden Fall Warten auch BDS 2007 angesagt.
Das wird hier wohl auch noch Thema werden...

Stefan

Stefan.Buchholtz hat folgendes geschrieben:

. Im Moment sehe ich auch keinen Haken ausser erhöhter Resourcenbedarf sowohl auf dem Datenbank-Server als auch auf den Clients. Stefan

Resourcenbedarf sollte wohl nicht mehr das Problem sein, auf der Festplatte ohnehin nicht. Die Serverbelastung hält sich
auch in Grenzen. Das Programm läuft ja auf dem gleichen Rechner und ob der User mit Modul A oder B arbeitet ist ja egal.
Startzeit spielt wohl auch keine Rolle. Ich habe einmal probiert, eine Exe mit Parametern ist nach ca. 44 ms gestartet.
Etwas länger dauert der Connect zur Datenbank.
BPL möchte ich eigentlich im Programm belassen um ein Einzelprogramm immer unabhängig am Laufen zu haben.
Ein Teil der Fenster ist jetzt modal.
Hier werde ich nach dem Start mit WaitForSingleObject die Funktion nachbauen.

die Delphi BPL (RTL und VCL) als Laufzeitbpl sparen pro Programm-Modul etwa 2 Mbyte.

Wenn Net, dann kann VCL.NET nur eine Übergangslösung sein, um Delphi und NET zu mischen und dann schrittweise
durch "reinrassiges" NET abzulösen.
Wenn sich das Konzept der VCL.NET in BDS 2007 nicht ändert, dann ist die VCL.Net keine tragbare Lösung.
(Sagt mein Chef.)

Gruß
Carla