|
Programm modularisieren
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 |
Re: Programm modularisieren
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 |
Re: Programm modularisieren
Zitat:
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 |
Re: Programm modularisieren
Zitat:
|
Re: Programm modularisieren
Zitat:
Gruß Peter |
Re: Programm modularisieren
Zitat:
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 |
Re: Programm modularisieren
Zitat:
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? |
Re: Programm modularisieren
Zitat:
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 |
Re: Programm modularisieren
Zitat:
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 |
Re: Programm modularisieren
Zitat:
Zitat:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 02:07 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz