Programm modularisieren

[hanspeter]

Ich suche immer noch nach einem gangbaren Weg ein großes Programm zu modularisieren.
Eine reine BPL Lösung ist dazu aus verschiedenen Gründen nicht praktikabel.
Ich habe deshalb mit Hydra von Remobjects experimentiert.
Hier bietet sich die Möglichkeit eine mit Hydra generierte dll auch in ein Net Programm einzubinden.
Bei dieser Lösung bekomme ich jedoch das BPL-Versionsproblem durch die Hintertüre.
Alle Componenten, welche sich mit RegisterClass registrieren, können projektweit nur in einer einzigen dll
eingebunden werden.
Der Umstand ist etwas tückisch, da der Registerfehler vom Ladezeitpunkt der dll abhängig ist.
Damit muss jede Componente mit Registerclass als Laufzeitbibliothek eingebunden werden.

Das Programm kann ich in mehrere unabhängige Teilprojekte zerlegen.
z.B. Reports , Datenpflege u.s.w.
Zur Interprocess-Kommunikation reicht ein record von max. 16 Byte Länge.
Spricht etwas dagegen, eine Modularisierung über EXE Files anzugehen?
Ich habe mir eine Klasse für das Handling über wm_CopyData geschrieben.
Das Modul hat ein nicht sichtbares Fenster. Die Caption ist eine GUID, damit läßt sich das Fenster eindeutig finden.
Das Hauptprogramm startet das Modul über die Shell und übergibt in der Comandline den Datenbank Connectstring.
Ein weiterer Vorteil wäre die Möglichkeit, abhängig von der Kommandozeile das Programm in einem Singlemodus, jetzt
mit einem eigenem Menü zu starten.
Programm und Modul laufen immer auf dem gleichen Rechner.

Hat so eine Lösung mit Exe-Files noch andere Fallstricke, die ich im Moment noch nicht sehe?
Ist wm_CopyData ein gangbarer Weg oder sollten Pipes oder Winsock bevorzugt werden?

Für eine Meinung dankbar.
Mit Gruß
Peter

[gabneo]

Hi,
soweit sich das mir darstellt, wird das größte Problem die Synchronisation der Prozesse/*.exe zueinander sein. Wenn eine exe auf das Resultat einer anderen wartet, kann das im Fall einer asynchronität (z.b. Message die erwartet wird geht verloren) bedeuten das deine gewünschte Aktion nie zuende geführt wird.

Doch aus meiner persönlichen Erfahrung, ich setze WM_Copydata auch sehr erfolgreich in Shareware ein....also ich denke das ist eine sehr gute Sache und auch unbedenklich auf mehreren verschiedenen Systemen einsetzbar.

greez
gabneo

[hanspeter]

Zitat:

Zitat von gabneo

Hi,
soweit sich das mir darstellt, wird das größte Problem die Synchronisation der Prozesse/*.exe zueinander sein. Wenn eine exe auf das Resultat einer anderen wartet, kann das im Fall einer asynchronität (z.b. Message die erwartet wird geht verloren) bedeuten das deine gewünschte Aktion nie zuende geführt wird.

Doch aus meiner persönlichen Erfahrung, ich setze WM_Copydata auch sehr erfolgreich in Shareware ein....also ich denke das ist eine sehr gute Sache und auch unbedenklich auf mehreren verschiedenen Systemen einsetzbar.
greez
gabneo

Eigentlich ist keine Synchronisation notwendig.
Es ist ja der gleiche Arbeitsplatz und nur ein Anwender.
Der Anwender klickt den Button Listendruck an und die Liste kommt. (oder auch nicht)
Ähnlich sieht es bei Dialogen aus.
Der Anwender wählt den Menüpunkt "Kunden bearbeiten".
Das Stammdatenbearbeitungsmodul wird gestartet und z.B. der Parameter 'K' für Kunde und z.B. 1234 für Kundennummer
übertragen.
Dabei wird quasi ein Showmodal nachgebildet.
Soll eine andere Bearbeitungsmaske geöffnet werden, wird die vorhergehende geschlossen.

Wenn ich VCL,RTL als Laufzeitbibliothek verwende, sollte sich auch die Programmgröße in Grenzen halten.

Gruß
Peter

[Bernhard Geyer]

Zitat:

Zitat von gabneo

Doch aus meiner persönlichen Erfahrung, ich setze WM_Copydata auch sehr erfolgreich in Shareware ein....also ich denke das ist eine sehr gute Sache und auch unbedenklich auf mehreren verschiedenen Systemen einsetzbar.

Hatten schon teilweise sehr schlechte Erfahrungen mit WM_COPYDATA (noch schlechter wenn Sender und Empfänger in einem Prozessraum waren), da diverse Tools wie NVidia-Desktopmanager, WebEx, ... einfach WM_COPYDATA-Messages verschluckt haben.

[hanspeter]

Zitat:

Zitat von Bernhard Geyer

Hatten schon teilweise sehr schlechte Erfahrungen mit WM_COPYDATA (noch schlechter wenn Sender und Empfänger in einem Prozessraum waren), da diverse Tools wie NVidia-Desktopmanager, WebEx, ... einfach WM_COPYDATA-Messages verschluckt haben.

Dann wohl doch lieber über ein namedpipe?

Gruß
Peter

[shmia]

Zitat:

Zitat von hanspeter

Ist wm_CopyData ein gangbarer Weg oder sollten Pipes oder Winsock bevorzugt werden?

Alle drei Wege kosten dich mehr Arbeit als Nutzen!
Du könntest dir ActiveX Bibliotheken aufbauen.
Ich habe z.B. den EMail-Versand komplett in eine ActiveX-DLL ausgelagert.
Das Hauptprogramm erzeugt einfach ein COM-Objekt, befüllt alle Parameter (Absender, Enpfänger, Subject,...) und ruft die SendMail() Methode auf. Fertig !

Hier mal meine Bewertung zu den versch. Techniken in bezug auf Modularisierung:

Code:

normale DLLs         - veraltet, nicht objekt-orientiert, aufwändig, fehlerträchtig (weil Parameter nicht typsicher)
BPL                  - nur innerhalb von Delphi Apps. Hat trotzdem gewisse Probleme
ActiveX              - leistungsfähig, erfordert aber sehr viel Wissen über COM/DCOM, lange Lernkurve
Corba                - ähnlich ActiveX, aber schon lange auf dem absteigenen Ast
.NET Assemblies      - so sollte es sein
WM_COPY              - Schrott, hat keine Zukunft unter Vista.
DDE                  - völlig veraltet (aber besser als WM_COPY)
TCP/IP, Named Pipes  - sehr aufwändig (man muss ein eigenen Protokoll entw.), nur für Netzwerkanwendungen empfehlenswert

[Bernhard Geyer]

Zitat:

Zitat von shmia

Du könntest dir ActiveX Bibliotheken aufbauen.

Bitte hier aber die Gefahr der DLL-Hölle aufgrund der nötigen Registrierung mit Admin-Rechten vergessen!

Aber hier die Ergänzung deiner Liste

Code:

normale DLLs         - Läuft mit jeder vernünftigen Programmiersprache, Kann auf jedem Windows Side-By-Side verteilt werden (Keine installation
ActiveX              - DLL-Hölle, Primär für IE-Integration entworfen.
Corba                - Wennst du genügend Zeit (und teilweise Geld hast) .... Ist aber eher mit DCOM/COM+ als mit ActiveX zu vergleichen, COM ist die Basistechnik für ActiveX
.NET Assemblies      - so sollte es sein wenn man auf .NET setzt
WM_COPY              - Hat keine Zukunft unter Vista: Jein. Hat halt die Probleme mit UAC.
DDE                  - Total veraltet. Ist AFAIK unter Win64 nicht mehr vorhanden
TCP/IP, Named Pipes  - Aufwendig aber Flexibel da auf sehr tiefer Ebene aufgesetzt wird
SOAP/Web Service     - Anzustreben wenn Plattformübergreifende, rechnerübergreifende Lösung gesucht wird

Kannst du den Hydra nicht ohne BPL/Laufzeitpackages verwenden?

[hanspeter]

Zitat:

Zitat von shmia

Alle drei Wege kosten dich mehr Arbeit als Nutzen!
Du könntest dir ActiveX Bibliotheken aufbauen.
Ich habe z.B. den EMail-Versand komplett in eine ActiveX-DLL ausgelagert.
Das Hauptprogramm erzeugt einfach ein COM-Objekt, befüllt alle Parameter (Absender, Enpfänger, Subject,...) und ruft die SendMail() Methode auf. Fertig !

Erst mal vielen Dank für Deine Aufstellung.

ActiveX hat den Nachteil, dass eine Registrierung erforderlich ist und der Testaufwand deutlich höher ist.
Gerade bei diesem Programm muss aber ein einfaches Kopieren in das Programmverzeichnis reichen.
Dadurch das Delphi bpl beinahe willkürlich nachkompiliert hat man mehr Probleme als auf Dll Basis.

Ich möchte das Programm modularisieren, da ein schrittweiser Übergang zu Net erfolgen soll.
Die geplante "lose" Koppelung sollte eigentlich die wenigsten Probleme bringen.

Gruß
Peter

[hanspeter]

Zitat:

Zitat von Bernhard Geyer

Kannst du den Hydra nicht ohne BPL/Laufzeitpackages verwenden?

Nein,
das habe ich schon im ersten Thread beschrieben.
Die Hydramodule benötigen VCL;RTL als runtime und jede bpl die ein Registrclass enthält, führt zu einem
Laufzeitfehler, wenn sie kein Laufzeitpackages ist.
Ich meine irgendwo gelesen zu haben, dass mann eine exe als dll aufrufen kann.
Wer da einen Tip hat?

Gruß
Peter

[Bernhard Geyer]

Zitat:

Zitat von hanspeter

das habe ich schon im ersten Thread beschrieben.

Hab ich wohl überlesen.

Zitat:

Zitat von hanspeter

Wer da einen Tip hat?

Wir haben selbst eine Plugin-Schnittstelle die für Kundenspezifische Erweiterung verwendet wird die nicht ins Hauptprogramm paßt. Alles sonstiges ist im "Moloch" des Hauptprogramms untergebraucht. Die Pluginschnittstelle wurde als C-Kompatible Schnittstelle entworfen so das wir dem BPL/Runtime-Package oder Sharemem-Problem aus dem weg gehen. Über die Pluginschnittstelle kann sogar die verwendete DB im Hauptprogramm verwendet werden. Auf Exe und DLL-Seite gibt es auch noch jeweils Wrapper-Klassen (evtl. Fassade-Muster :gruebel:) so das die auch noch halbwegs gekapselt ist und wird laufen ganz gut damit.

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

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