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 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 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 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 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 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 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 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 von hanspeter:

das habe ich schon im ersten Thread beschrieben.

Hab ich wohl überlesen.

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 ) so das die auch noch halbwegs gekapselt ist und wird laufen ganz gut damit.