Soll ich in Delphi gemeinsame Projekte zu meinen Projekten hinzufügen, zu einem geteilten Paket oder zu keinem?

7

Diese Frage ähnelt dieses , aber kein Duplikat, weil ich nach Themen frage, die in dieser Frage nicht behandelt werden.

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

%Vor%

Es gibt 2 tatsächliche Delphi-Projekte (.dpr), jeweils eine in den Ordnern MyClientApp und MyServerApp.

Der lib-Ordner verfügt über .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 lib-Ordner 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 geöffneten Dateien mache oder die grep-Suche benutze (aber ich würde eine bessere Lösung bevorzugen).

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

    
Liron Yahdav 12.02.2009, 23:10
quelle

5 Antworten

8

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 hinzufügt, um sie zu ändern, ohne andere Programme zu berücksichtigen.

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

Sie in ein Paket zu packen macht nur dann Sinn, wenn Sie tatsächlich eine paketbasierte Anwendung erstellen möchten, ansonsten sollten Sie sich die Mühe machen?

Weitere Informationen darüber, wie ich meine Projekte und Bibliotheken organisiere, finden Sie Ссылка

    
dummzeuch 13.02.2009, 07:38
quelle
5

Ich möchte nicht, dass Dateien von Projekten geteilt werden. Allzu oft werden Sie versucht sein, eine der freigegebenen Dateien zu bearbeiten, und Sie werden entweder etwas in dem anderen Projekt unterbrechen oder Sie werden 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.

Halten Sie Ihre DCU-Dateien von Ihren PAS-Dateien getrennt. 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 Mitglied ist.

Das Verwenden eines separaten Pakets verhindert auch die Verwendung projektspezifischer bedingter Definitionen. 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 je nach dem, wer sie verwendet, anders handeln muss, verwenden Sie Techniken wie Callback-Funktionen, die der Bibliotheksbenutzer einstellen kann, um das Verhalten der Bibliothek zu ändern.

    
Rob Kennedy 13.02.2009 00:19
quelle
4

Ich müsste einen sehr guten Grund haben, einen geteilten Code zu einem Paket hinzuzufü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.

    
Toby Allen 13.02.2009 11:02
quelle
3

Normalerweise erstelle ich ein Paket mit allen gemeinsam genutzten 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.

    
Cesar Romero 13.02.2009 00:04
quelle
2

Ich würde Laufzeit-Pakete nur verwenden, wenn Sie tatsächlich zwei Binärdateien hätten, die auf demselben physischen Computer ausgeführt werden sollten und die etwas Code enthielten. Denken Sie daran, dass Laufzeit-Pakete meistens ein Alles-oder-Nichts-Ansatz sind. Sobald Sie sich entscheiden, sie zu verwenden, werden Sie auch nicht mehr in der Lage sein, die RTL- und VCL-Einheiten direkt mit Ihren Projekten zu verknüpfen 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, sodass 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 Sie für die Suche in Dateien auch "in allen Dateien in der Projektgruppe" angeben können

    
Oliver Giesen 13.02.2009 15:44
quelle

Tags und Links