In Delphi, sollte ich geteilte Einheiten zu meinen Projekten, zu einem geteilten Paket hinzufügen, oder zu keinem?

Question

Diese Frage ist ähnlich wie this one, aber kein Duplikat, weil ich Fragen über Fragen, die nicht in dieser Frage diskutiert werden.

Ich habe ein Client-Server-Projekt in Delphi 7 mit der folgenden Verzeichnisstruktur:

\MyApp 
    \MyClientApp 
    \MyServerApp 
    \lib 

Es gibt zwei aktuelle Delphi-Projekte (.dpr), jeweils in der MyClientApp und MyServerApp Ordnern.

Der lib-Ordner enthält .pas-Einheiten, die einen gemeinsamen Code für die Client- und Server-Apps haben. Ich frage mich, ob ich diese .pas-Dateien in die Client- und Server-Projekte aufnehmen sollte? Oder sollte ich ein Paket im lib-Ordner erstellen, der diese Einheiten enthält? Oder sollte ich die .pas-Dateien einfach im lib-Ordner belassen und sie keiner App/keinem Paket hinzufügen?

Was sind die Vor-/Nachteile jedes Ansatzes? Welcher Weg ist "der Beste"? Gibt es ein Problem damit, diese Einheiten aus dem lib-Ordner in mehr als ein Projekt aufzunehmen?

Momentan sind die Einheiten im Ordner lib nicht Bestandteil einer App/eines Pakets. Ein Nachteil davon ist, dass, wenn ich meine Client-Anwendung beispielsweise in Delphi geöffnet habe und ich in allen Dateien im Projekt nach etwas suchen möchte, nicht auch in den Einheiten im lib-Ordner suche. Ich komme dazu, indem ich diese Einheiten öffne und einen Fund in allen offenen Dateien mache oder die grep Suche benutze (aber ich würde eine bessere Lösung bevorzugen).

Ich würde auch eine Lösung bevorzugen, wo ich nicht gehen und ein separates Paket öffnen und neu kompilieren muss, wenn ich Änderungen an diesen Dateien im lib-Ordner mache (soll ich eine Projektgruppe verwenden?).

Answer 1

Das Teilen von Einheiten zwischen Anwendungen birgt immer das Risiko inkompatibler Änderungen in einer Anwendung, die die andere bricht. Auf der anderen Seite ist das Erstellen von Kopien dieser Einheiten noch schlimmer, so dass Ihr Approcach, sie in ihr eigenes Unterverzeichnis zu verschieben, zumindest eine psychologische Barriere bietet, diese zu ändern, ohne andere Programme zu berücksichtigen.

Zum Hinzufügen zu den Projektdateien: Ich füge normalerweise einige Einheiten hinzu, auf die ich häufig (entweder zum Erweitern oder als Referenz) von der IDE zum Projekt zugreife, und andere für den Compiler, die den Suchpfad auswählen . Ich mache das auf Projektbasis, das heißt, einige Einheiten können Teil mehrerer Projekte sein, warum nicht?

Das Einfügen in ein Paket macht nur dann Sinn, wenn Sie tatsächlich eine paketbasierte Anwendung erstellen möchten, anderenfalls, warum?

Weitere Informationen darüber, wie ich meine Projekte und Bibliotheken organisieren finden http://www.dummzeuch.de/delphi/subversion/english.html

Answer 2

Ich erstelle normalerweise ein Paket mit allen geteilten Einheiten und verwende einfach die Einheiten. Wenn Sie "Build with run time packages" nicht explizit markieren, wird der Paketinhalt (alle verwendeten dcu's) wie jede andere Einheit mit Ihrem Projekt verknüpft.

Answer 3

Ich mag es nicht, Dateien von Projekten geteilt zu haben. Allzu oft werden Sie versucht sein, eine der freigegebenen Dateien zu bearbeiten, und Sie werden entweder im anderen Projekt etwas kaputt machen oder vergessen, dass Sie das andere Projekt überhaupt neu erstellen müssen.

Wenn die freigegebenen Dateien stattdessen in eine eigene Bibliothek (Paket) getrennt werden, gibt es eine kleine zusätzliche Barriere für die Bearbeitung. Ich halte das für eine gute Sache. Es wird eine leichte Erinnerung daran sein, dass Sie von projektspezifischem Code zu gemeinsam genutztem Code wechseln. Sie können Projektgruppen verwenden, damit Sie alle in einer einzigen IDE-Instanz zusammenhalten können. Ordnen Sie die Bibliotheksprojekte vor den ausführbaren Projekten an. Der Befehl "build all" baut alles ab dem ersten Projekt auf.

Behalten Sie Ihre DCU-Dateien getrennt von Ihren PAS-Dateien. Sie können dies ganz einfach tun, indem Sie die Projektoption "DCU-Ausgabeverzeichnis" so einstellen, dass die Einheiten Ihres Pakets an einen anderen Ort gesendet werden. Dann legen Sie dieses Zielverzeichnis auf den Suchpfad Ihres anderen Projekts. Sie werden die DCU finden, aber sie werden die PAS-Datei nicht finden, und so wird kein anderes Projekt versehentlich eine Einheit neu kompilieren, die nicht wirklich ein Mitglied ist.

Mit einem separaten Paket wird auch die Verwendung von projektspezifischen bedingten definiert. Diese verursachen alle Arten von Problemen, wenn Sie Einheiten zwischen Projekten teilen. Finden Sie einen Weg, um alle projektspezifischen Optionen innerhalb der jeweiligen Projekte zu behalten. Eine gemeinsam genutzte Bibliothek sollte keine projektspezifischen Änderungen erfordern. Wenn eine Bibliothek basierend auf dem, der sie verwendet, unterschiedlich agieren muss, verwenden Sie Techniken wie Callback-Funktionen, die der Bibliotheksbenutzer einstellen kann, um das Verhalten der Bibliothek zu ändern.

Answer 4

Ich würde einen sehr guten Grund haben, muß gemeinsamen Code zu einem Paket hinzufügen. Wenn Sie nur ein paar freigegebene Dateien haben, kleben Sie sie alle in ein Verzeichnis namens Shared. Dies sollte es offensichtlich machen, dass die Dateien zwischen Projekten geteilt werden.

Verwenden Sie auch ein gutes Build-Tool, um automatisierte Builds zu erstellen, so dass Sie bald genug herausfinden werden, wenn Sie etwas kaputt machen.

.bpl-Dateien sind für Komponenten in Ordnung, bringen aber eine erhebliche zusätzliche Komplexität für solche Dinge mit sich, es sei denn, Sie haben eine große Menge an freigegebenen Dateien.

Answer 5

Ich würde Laufzeit-Pakete nur verwenden, wenn Sie tatsächlich zwei Binärdateien hatten, die auf demselben physischen Computer ausgeführt werden sollten und die etwas Code teilten. Denken Sie daran, dass Laufzeit-Pakete meistens ein Alles-oder-Nichts-Ansatz sind. Sobald Sie sich für die Verwendung entschieden haben, können Sie die RTL- und VCL-Einheiten nicht mehr direkt in Ihre Projekte einbinden und müssen diese stattdessen auch separat bereitstellen.

Pakete können jedoch immer noch eine gute Lösung für Ihr Problem sein, wenn sie mit Projektgruppen kombiniert werden, was genau ich mache. Ich hasse es, Einheiten geteilt zu haben, die in mehreren Projekten enthalten sind. Wenn Sie die gemeinsam genutzten Einheiten in ein Paket aufnehmen (aber Ihre eigentlichen Projekte nicht mit Laufzeitpaketen kompilieren), können Sie dieses Paket zu Ihrer Projektgruppe hinzufügen, so dass Sie (und die IDE!) Immer leicht zugänglich und dennoch von den projektspezifischen getrennt sind Code. Genau genommen müssen Sie diese Pakete nicht einmal kompilieren. Sie können lediglich als organisatorische Einheit im Projektmanager dienen.

Beachten Sie, dass für das Suchen in Dateien, können Sie auch „in allen Dateien in der Projektgruppe“ angeben