Hallo,
wir haben mehrere Möglichkeiten untersucht einen vorhandenen Delphi-Text zu modularisieren. Letztendlich sind wir zu der Entscheidung gekommen, das Projekt auf Quelltextebene zu modularisieren, für den Anwender dann aber als eine EXE auszuliefern.

Wir planen nachfolgende Struktur

Projektverzeichnis
BPL
DCU
DCL
Coomon
Quellen
Modul1
Modul2
Moduln
Die Module kennen nur ihr eigenes Verzeichnis und das Common-Verzeichnis.
Jedes Modul ist als BPL organisiert.
Alle BPL werden in dem Verzeichnis BPL abgelegt.

Hier ist jetzt mein Verständnisproblem.
Habe ich ein Modul welches eine andere BPL benötigt, so muss ich ja unter Uses die Unit und nicht die BPL einbinden.
Wie findet jetzt der Compiler die BPL, welche das gewünscht Unit enthält? Das Verzeichnis DCU soll nicht im Suchpfad sein.
Bei den BPL handelt es sich nicht um Komponenten. Diese werden also nicht registriert.

z.B. BPL - Kundenverwaltung, BPL Listendruck u.s.w.
Laufzeitpackages sollen unter allen Umständen vermieden werden, da diser mehr Probleme als Nutzen brinen.

Für ein paar klärende Hinweise dankbar.

Mit den besten Wünschen für ein gesegnetes Weihnachtsfest
Carla

Du musst dem Compiler den DCU-Pfad für die einzubindenden Units zwar sagen, wenn Du aber das Package erstellst, musst Du zusätzlich in diesem Package die anderen BPLs, von denen dein Modul abhängt mit ansagen.

Der Compiler versucht zuerst jede Unit mit in eine ausführbare Datei mit aufzunehmen (egal ob Anwendung, DLL oder Package). Wenn Du mit Laufzeit-Packages compilierst, dann sucht der Compiler nach DCP-Files. Diese beschreiben den Inhalt eines Packages. Anhand dieser Informationen werden dann statische Importe aus diesem fremden Package gemacht, wodurch die Units, die in diesem anderen Package liegen, nicht mehr in das zu compilierende Modul aufgenommen werden brauchen. Stattdessen rd für jeden Aufruf einer Unit aus dem andren Package einfach ein Funktionsaufruf gemacht, als ob Du eine WinAPI-Funktion aufrufen würdest.

Beispiel:

Package A enthält units U1,U2 und U3 und Package B enthält U4. Wenn Du nun Package B compilierst und Unit U4 auf z.B. U2 zugreift, dann wird nicht U2 in Package B eingebunden, sondern lediglich markiert, dass Package B Package A benötigt und die Unit U2 wird nun von dort verwendet.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Warum organisiert du das nicht mit DLLs? DIe Einbindung derjenigen ist einfach und sie sind auch austauschbar.
z.b.
- EXE -> enthält nur die Oberfläche
- DLL1..n-> enthält Funktionen modularisiert nach Themen (z.b. Kunden-DLL, Produkt-DLL, Web-DLL u.s.w.)
- DLLA -> enthält alle Strings z.b. Nachrichten in n Sprachen
- DLLZ -> enthält die Datenbankverbindungsverwaltung sofern notwendig
- DLLR -> enthält alle Resourcen wie Bilder, Icons etc.

Mit BPLs ziehst du dir meiner Meinung nach mehr Overhead rein als notwendig - und sie sind zu nichts kompatible.

Du brauchst dir zusätzlich keine Verzeichnisstruktur merken wo was liegt. DLls können nur im System- bzw. Programmverzeichnis liegen.

Nimm zusätzlich das dynamische Linken (statt Statisch) und du kannst funktionalitäten anhand von dem Vorhandensein
von DLLs ein- bzw. ausblenden- je nachdem was du lieferst.

Noch besser wäre es, du lieferst due Logik nicht in der EXE, sondern als SOAP-Service mit. Das ist relativ einfach zu bewerkstelligen - ein IIS (Kleine oder Große Variante) kann auf jedem Windows nachinstalliert werden. Dann hast du eine kleine Exe mit der Oberfläche und einen Webservice der die Funktionalität liefert. Auch hier ist der Mehrwert letztendlich davon abhängig, was du entwickelst. Für eine simple Titelverwaltung wäre das wahrscheinlich Overkill - für eine gute ERP Anwendung aber ein Muss heutzutage.

:-)Msch

Bpls sind eigentlich Dlls mit der erweiterten Möglichkeit, Delphi-Objekte im Interface verwenden zu können.

information findest du auch hier:

entwickler-forum.de/...dex.php/t-24490.html

:-)Msch

MSCH hat folgendes geschrieben :

Warum organisiert du das nicht mit DLLs? DIe Einbindung derjenigen ist einfach und sie sind auch austauschbar :-)Msch

Das hatten wir auch untersucht.
Ich persönlich halte die BPL für einen Design-Fehler in Delphi.
Mit Dll muss ich entweder mit Laufzeitpackages arbeiten und mit diesen sind wir gehörig auf die Nase gefallen oder ich binde die benötigten BPL in die dll mit ein und habe pro dll einen Overhead von etwa 2,5 Mbyte. Wir hatten dann das dll Framework Hydra von Remobjects verwendet. Hier müssen aber auch viele BPL als Laufzeit-BPL bereitgestellt werden. Vor allen auch solche, welche im gesamten Programm garantiert nicht verwendet werden.(z.B. BDE)

SOAP Dienste klingt interessant. Damit habe ich mich aber noch nicht beschäftigt.
Wir haben eiun großes Delphiprogramm übernommen. Dieses soll für die Programmpflege besser modularisiert werden. Neue Projekte beginnen wir nicht mehr in Delphi.

Mit den besten Wünschen für ein gesegnetes Weihnachtsfest

Carla

Carla hat folgendes geschrieben :

Ich persönlich halte die BPL für einen Design-Fehler in Delphi.

Hast du mit D1(D2?) gearbeitet als es diese modulare Packagekonzept noch nicht gab? Dort gab es regelmäßig das Problem das eine fehlerhafte Komponente eine Start der Delphi-IDE verhindert hat. Jetzt läd die IDE einfach nicht die fehlerhafte Package und gut ist. Leider wurde das konzept seit dieser Zeit nicht viel weiterentwickelt so das Package-Konzept von Java/.NET heutzutage einfach besser ist.

Ich würde das Modulierungskonzept auf Exe/DLL-Ebene nicht übertreiben. Eine einzelne Exe hat einen großen Charme das man keinerlei DLL-Hölle zu fürchten braucht.

[quote="[user]Bernhard Geyer
Ich würde das Modulierungskonzept auf Exe/DLL-Ebene nicht übertreiben. Eine einzelne Exe hat einen großen Charme das man keinerlei DLL-Hölle zu fürchten braucht.[/quote]

Ja in der Richtung geht ja meine Frage.
Wir wollten das Projekt auf BPL Ebene modularisieren.
Also eine BPL Auftragsverwaltung, eine BPL Report u.s.w. anfangs haben wir diese als Komponente eingebunden (ohne visuelle Funktionalität).
Dann nur dem Projekt dazugelinkt. Deswegen auch meine Verständnisfrage.
Aber so einen richtigen Vorteil kann ich nicht erkennen.
Alles in einer Exe ergibt die kleinste Lösung Exe + 1 dll ist schon deutlich größer und bringt zusätzliche Probleme.
Nein mit D1/D2 habe ich nicht gearbeitet. Ich selbst komme aus der C++/jetzt C# Ecke.
Unsere Firma hat das Projekt, samt Delphiprogrammierer übernommen. Der schwärmt von seiner Sprache. Mir selbst sträuben sich jedoch immer mehr die Nackenhaare, je tiefer ich in Delphi eindringe.

Gruß
Carla

Ich persönlich würde auf alle BPL verzichten und nur mit PAS/DCU arbeiten. Frag mich nicht wieso, aber hier bin ich -glaube ich- einfach konservativ. Auch verwende ich keine Module, sondern separate EXEn.

Ansonsten sind meine Projektverzeichnisse so aufgebaut.
APP
Shared (Common)
Modul1
Modul2
Modul3

Ich verbiete Abhängigkeiten zwischen einzelnen Programmen. Jedes Projekt kennt nur sein eigenes und das 'Shared' Verzeichnis. Dann hab ich noch einen 'APP'-Ordner, wo alle EXEn hineinkompiliert werden.

alzaimar hat folgendes geschrieben :

Ich persönlich würde auf alle BPL verzichten und nur mit PAS/DCU arbeiten. Frag mich nicht wieso, aber hier bin ich -glaube ich- einfach konservativ. Auch verwende ich keine Module, sondern separate EXEn. Ich verbiete Abhängigkeiten zwischen einzelnen Programmen. Jedes Projekt kennt nur sein eigenes und das 'Shared' Verzeichnis. Dann hab ich noch einen 'APP'-Ordner, wo alle EXEn hineinkompiliert werden.

Ein sehr interessanter Ansatz, der einige Probleme vermeidet. Aber mit welcher Methode erfolgt ein Datenaustausch zwischen den Exe?

Mit Gruß
Carla

Carla hat folgendes geschrieben :

Ja in der Richtung geht ja meine Frage. Wir wollten das Projekt auf BPL Ebene modularisieren. Also eine BPL Auftragsverwaltung, eine BPL Report u.s.w. anfangs haben wir diese als Komponente eingebunden (ohne visuelle Funktionalität). Dann nur dem Projekt dazugelinkt. Deswegen auch meine Verständnisfrage.

Du kannst Packages in der IDE verwenden (z.B. ein Base-Package + 1-2 "Feature"-Packages) und die Exe dann ohne Packages kompilieren (bzw. deine eigenen Packages aus der Liste der für die Runtime zu verwendenten Packages ausnehmen).

Falls du Kundenspezifische Erweiterungen benötigst überleg dir eine C-Kompatible Schnittstelle, damit du auch zur Laufzeite die Probleme von BPL's aus den Weg gehst. Dann ist zwar die DLL etwas größer, aber was solls. Du bist Versionssicher. Du kannst ja auch nicht einfach unter .NET eine 1.1-Assembly in deiner 2.0 Exe verwenden wenn die DLL etwas verwendet was sich mit .NET 2.0 geändert hat und dort nicht laufen würde (Nur eine .NET-Version in einem Prozess-Adressraum möglich).

Carla hat folgendes geschrieben :

Ein sehr interessanter Ansatz, der einige Probleme vermeidet. Aber mit welcher Methode erfolgt ein Datenaustausch zwischen den Exe?

IPC bzw. TCP bei Client/Server.

ich binde die benötigten BPL in die dll mit ein und habe pro dll einen Overhead von etwa 2,5 Mbyte.
wozu gibts denn laufzeitpacker? (UPX). Damit dampfst du dann die DLLs und Exe wieder ein.

:-)Msch