Projektstruktur (nicht alles in einem Ordner)

[Rollo62]

Hallo zusammen,

aus dem Post hier springt mir der obige Satz ins Gesicht.

Ich bin auch ein großer Fan von Verzeichnissen und Unterverzeichnissen, und würde das sehr strukturiert einsetzen.
Leider werde ich dabei immer durch Delphi gebremst weil der Support von "Unter"verzeichnissen dort "Unter"irdisch ist.
Wenn dann will ich die Verwaltung in den Units selbst machen, und nicht in der IDE.

Deshalb bin ich schon länger bei der Fraktion Viele Units in wenige Verzeichnisse zu werfen, und
dann lieber über klar strukturierte Namespaces eine Form reinzubringen.

Also statt

Delphi-Quellcode:

Feature1\Detail1_1\Unit1_1.pas
Feature1\Detail1_2\Unit1_2.pas
Feature1\Detail1_3\Unit1_3.pas
Feature2\Detail2_1\Unit2_1.pas
Feature2\Detail2_2\Unit2_2.pas

schreibe ich lieber

Delphi-Quellcode:

Feature1.Detail1_1.Unit1_1.pas
Feature1.Detail1_2.Unit1_2.pas
Feature1.Detail1_3.Unit1_3.pas
Feature2.Detail2_1.Unit2_1.pas
Feature2.Detail2_2.Unit2_2.pas

Nur für klar abgegrenzte Funktionalitäten würde ich eigene Unterverzeichnisse vorsehen.
So spare ich mir die ganze Pflege der Verzeichnisstruktur (welche ich liebend gern in den Units selbst machen würde, was aber nicht geht).

Ich finde auch öfters das Muster

Delphi-Quellcode:

Models\Feature1_Model.pas
ViewModels\Feature1_VM.pas
Views\Feature1_View.pas

was für mich auf den ersten Blick schön sauber aussieht, aber den erheblichen Nachteil hat
dass die zusammengehörigen Teile auseinandergerisssen werden.
(ja ich weiss das die eigentlich nicht zusammen hängen sollen, das tun sie aber meist eben doch).

Ich sehe in dem Aufbau in einem Verzeichnis keinerlei Nachteil:

Delphi-Quellcode:

Feature1_Model.pas
Feature1_ViewModel.pas
Feature1_View.pas

eher nur Vorteile

Oder irre ich mich da,
welchen konkreten Vorteil hätte das konsequente Auseinanderziehen in Verzeichnisse und Unterverzeichnisse,
ausser das es erheblich mehr Verwaltungsaufwand bedeutet ?

Vielleicht gibt es ja dazu eine klare Theorie zur Programmstruktur, würde mich mal interessieren.
(oder ist es eben doch nur Geschmackssache ?)

[Der schöne Günther]

Ich sehe nicht weshalb die Teile "auseinandergerissen" werden, oder weshalb es eine erhöhten Verwaltungsaufwand bedeutet.

Manche Dinger bekommt man aufgrund der IDE nicht auseinander, z.B. bei grafischen Formularen/Frames die .pas-Datei und die dazu passende .dfm, die müssen im gleichen Ordner liegen.

Auch dein "statt" muss nicht sein: Es zwingt dich ja keiner wie die Dateien heißen müssen, und dem Projekt ist es völlig egal wo die Dateien liegen.

Beispiel:

Code:

.\MyProject.dpr
.\src\Fizz\Buzz\Fizz.Buzz.pas
.\src\Fizz\Buzz\Fizz.Buzz.LookupTable.pas
.\src\Fizz\Buzz\Fizz.Buzz.Strings.pas
(...)

[bernau]

Meist habe ich mehrere Projekte (bis zu 10) die in einer Projektgruppe zusammengefasst sind. Da sind Projekte dabei, die > 500 Units haben. Ein Großteil der Units wird von den Projekten geteilt.

Früher habe ich viel in Unterverzeichnisse aufgeteilt. Der Nachteil war, dass auch viele Suchpfade angegeben werden mussten oder neue Units dann in allen Projekten zugefügt werden mussten.

Das habe ich nun geändert, seit dem es Namespaces gibt. Unitnamen mit Namespaces lassen sich einfach besser lesen und organisieren.

Ich bin schon seit einiger Zeit damit beschäftigt Units umzubenennen, die Unterverzeichnisse aufzulösen und alles in ein Verzeichnis zu verschieben. Ich find es klasse. Ist aber Geschmackssache.

[Rollo62]

Zitat von bernau:

Meist habe ich mehrere Projekte (bis zu 10) die in einer Projektgruppe zusammengefasst sind. Da sind Projekte dabei, die > 500 Units haben. Ein Großteil der Units wird von den Projekten geteilt.

Früher habe ich viel in Unterverzeichnisse aufgeteilt. Der Nachteil war, dass auch viele Suchpfade angegeben werden mussten oder neue Units dann in allen Projekten zugefügt werden mussten.

Das habe ich nun geändert, seit dem es Namespaces gibt. Unitnamen mit Namespaces lassen sich einfach besser lesen und organisieren.

Ich bin schon seit einiger Zeit damit beschäftigt Units umzubenennen, die Unterverzeichnisse aufzulösen und alles in ein Verzeichnis zu verschieben. Ich find es klasse. Ist aber Geschmackssache.

+1 Exakt, das kann ich unterschreiben.

Fragt sich nur ob es irgendeine Theorie gibt warum das Eine besser ist als das andere ?

@Der schöne Günther
... weshalb höherer Verwaltungsaufwand ...

• Weil ich öfters neue IDE Versionen aufsetzen muss, nicht wie damals wo eine Installation 2 Jahre hielt.
  Jedes Mal muss dann die ganze Verzeichnisstruktur aktualisiert werden
  Ok, hält sich in Grenzen, aber eigentlich wäre mir Plug-and-Play lieber
• Weil das Rein- und Rausspringen in Verzeichnissen, um z.B. eine Datei zu finden, doch mehr Aufwand ist als wenn Alles nebeneinander liegt.
  Dazu benutze ich eine Filtersuche, und bin Ruckzuck am Ziel.
• Weil ich wenn es irgendwelche fehlerhaften, z.B. doppelten Units gibt, ich mühevoll suchen muss wo es jetzt falsch drin ist.
  Während wenn die Daten alle Units nebeneinander liegen können gar keine doppelten Unit-Namen auftreten.
  Solche Probleme kenne ich seitdem nicht mehr.

[haentschman]

Zitat:

Projektstruktur (nicht alles in einem Ordner)

Eine gute Mischung aus Namespaces und Ordnerstuktur ist imho gut. Zu viele Ordner sind auch eher kontraproduktiv.

Bild1: meins
Bild2: so eher nicht...

[bernau]

Bei mir sieht es eher wie in Bild 2 aus. Vielleicht 3-4 Verzeichnisse um "grob" zu unterteilen. Ansonsten alles in ein Verzeichnis.

[himitsu]

Zitat von bernau:

Früher habe ich viel in Unterverzeichnisse aufgeteilt. Der Nachteil war, dass auch viele Suchpfade angegeben werden mussten oder neue Units dann in allen Projekten zugefügt werden mussten.

Wenn du diese Units explizit in die Projekte aufnimmst, dann braucht keine Suchpfade.
Der Suchpfad relative Pfad (absolut, wenn andere Partition) steht dann zu jeder Unit in der DPR.

Aber ja, ich habe seit einer Weile auch auf wenige größere Verzeichnisse umgestellt, genau aus dem selben Grund,
aber verwende dafür nun exzessiver die Namespaces in den Unitnamen.

[bernau]

Zitat von himitsu:

Wenn du diese Units explizit in die Projekte aufnimmst, dann braucht keine Suchpfade.

Normalerweise wird auch jede Unit bei mir explizit aufgenommen. Weil dann auch z.B. ein Grep zuverlässig funktioniert.

Aber wenn man in einem Projekt eine oder mehrere Units neu erzeugt und in bestehenden Units referenziert hat, dann hat man Probleme, wenn man "mal" alle Projekte durchkompilieren will.

[Rollo62]

Ich bin nicht sicher ob diese "Namespaces" mit '.' auch unter Lazarus und FPC funktionieren.
Meiner Meinung nach war das mal ein Problem, habs nie gecheckt.

Ach ja, "Namespaces" sind ja eigentlich mehr als nur '.' Bezeichnungen.
Trotzdem wissen hoffentlich Alle wie es gemeint ist.

@bernau
Ich nutze auch gerne externe Tools statt dem Grep in der IDE.
Das ist mir sowieso etwas zu beschränkt.


Also bis jetzt spricht erstmal nichts Grundsätzliches gegen die mehr flache Lösung,
da bin ich aber froh

[Delphi.Narium]

Statt . kann man ja auch den _ nehmen. Funktioniert bei meinem ollen Delphi 7 schon seit ewig und drei Tagen.

Neue Delphis kommen damit auch klar und FreePascal bestimmt auch.

Und ob die optische Trennung nun durch . oder _ erfolgt, sollte nur ein bisserl Gewohnheitssache sein. Dürfte aber letztlich gleich gut zu unterscheiden sein.

Alles was nur zu einem Projekt gehört, liegt bei mir im Projektverzeichnis.

Für Komponenten, die "überall" gebraucht werden können, gibt es ein Verzeichnis Komponenten. Fremdkomponenten erhalten dort ein Unterverzeichnis mit ihrem Namen. JCL, JVCL ...

Für Frames gibt es eine Verzechnis Frames, in das halt alle Units kommen, die in unterschiedlichen Projekten genutzt werden und Frames enthalten.

Units mit diversen "Hilfroutinen" sind im Verzeichnis Tools. Vom Aufgabengebiet her zusammengehörende Hilfsroutinen kommen in eine Unit für dieses Aufgabengebiet. Ist also alles schön sachlich sortiert.

Jedes Projekt hat sein eigenes Projektverzeichnis.

In der Regel sind die Projekte so konfiguriert, dass sie alle die DCUs in das gleiche Verzeichnis schreiben, kompilierte Packages kommen auch in ein Verzeichnis, dito Exen.

Alles liegt auf einem Laufwerk in 'nem Verzeichnis Delphi.

Code:

Laufwerk:
  Delphi
    _bpl
    _dcu
    _exe
    Komponenten
      JCL
        und hier halt die Struktur der JCL
      JVCL
        und hier halt die Struktur der JVCL
      ...          
    Frames
    Tools
    Je Projekt ein Verzeichnis

Für mich ist das in punkto Übersichtlichkeit ausreichend.

Damit Delphi beim Kompilieren nicht so ewiglange suchen muss und die Suchpfade nicht unübersichtlich groß werden, werden alle benötigten Dateien ins Projekt aufgenommen. Gut: Die DPR kann dann schonmal was länger werden, aber da muss man für gewöhnlich eh nicht ran, kann aber in der Projektverwaltung recht schnell sehen was man so alles ins Projekt eingebunden hat und die Dateien schnell in der IDE zur Bearbeitung öffnen.