Paketstruktur für ein Java-Projekt?

115

Was ist die beste Vorgehensweise zum Einrichten von Paketstrukturen in einer Java-Webanwendung?

Wie würden Sie Ihren Quellcode, Ihren Unit-Test-Code usw. einrichten?

java packages

— Mawaldne
quelle

94

Sie können dem Standard-Projektlayout von maven folgen . Sie müssen Maven eigentlich nicht verwenden, aber dies würde den Übergang in Zukunft erleichtern (falls erforderlich). Außerdem werden andere Entwickler daran gewöhnt sein, dieses Layout zu sehen, da viele Open Source-Projekte auf diese Weise angelegt sind.

— Johnstok
quelle

2

Ich empfehle auch, Mavens Layout zu verwenden, wenn Sie die Wahl haben. Es ist eine gut durchdachte Struktur, die kampferprobt wurde und vielen Entwicklern bekannt ist.

— Dov Wasserman

14

Mit diesem Oneliner können Sie das Verzeichnislayout erstellen: mkdir -p src / {main / {Java, Ressourcen, Filter, Assembly, Konfiguration, Webanwendung}, Test / {Java, Ressourcen, Filter}, Site}

— Daniel Hepper

1

Mavens Standard-Projektlayout ist hässlich ...: /

— Yousha Aleayoub

2

@ YoushaAleayoub Sie müssen es nicht heiraten

— Ashvin Sharma

59

Es gibt einige vorhandene Ressourcen, die Sie möglicherweise überprüfen:

Meine persönlichen Richtlinien, die ich normalerweise verwende, lauten wie folgt:

Beginnen Sie mit der umgekehrten Domain, z. B. "com.mycompany".
Verwenden Sie den Produktnamen, z. B. "myproduct". In einigen Fällen habe ich häufig verpackte Pakete, die nicht zu einem bestimmten Produkt gehören. Diese würden nach der Funktionalität dieser allgemeinen Klassen kategorisiert, z. B. "io", "util", "ui" usw.
Danach wird es freier. Normalerweise gruppiere ich nach Projekt, Funktionsbereich, Bereitstellung usw. Zum Beispiel könnte ich "Projekt1", "Projekt2", "Benutzeroberfläche", "Client" usw. haben.

Ein paar andere Punkte:

In Projekten, an denen ich gearbeitet habe, kommt es häufig vor, dass Paketnamen aus der Konstruktionsdokumentation stammen. In der Regel sind Produkte bereits in Funktions- oder Verwendungsbereiche unterteilt.
Machen Sie sich nicht zu viele Gedanken darüber, wie Sie allgemeine Funktionen sofort in höhere Pakete integrieren können. Warten Sie, bis ein Bedarf für Projekte, Produkte usw. besteht, und überarbeiten Sie dann den Refactor.
Beobachten Sie die Abhängigkeiten zwischen Paketen. Sie sind nicht alle schlecht, aber es kann eine enge Kopplung zwischen möglicherweise getrennten Einheiten bedeuten. Es gibt Tools, mit denen Sie den Überblick behalten können.

— Lycono
quelle

2

Ist im Fall der umgekehrten Domäne ("com.mycompany") das "com" -Paket normalerweise leer, mit Ausnahme des Unterpakets "mycompany"?

— Alex Parker

45

Ich würde vorschlagen, Ihre Paketstruktur nach Funktionen und nicht nach Implementierungsschicht zu erstellen. Ein guter Bericht dazu sind Java-Praktiken: Paket nach Feature, nicht Layer

— Daten Analyst
quelle

2

Vielen Dank. Dies ist, was ich gesucht habe, um meine Gedanken an das Team zu übermitteln

— Pranalee

8

Und wenn Sie die Datenbank wechseln möchten? Muss nur in 30 verschiedenen Paketen suchen. Von SFTP zu Webservices wechseln? Auch hier muss man nur an 30 verschiedenen Stellen suchen. Auf keinen Fall ein Fan.

— SamuelKDavis

1

Ein weiteres Beispiel, bei dem das Packen nach Layern Vorteile bietet: Wenn Sie Klassen in JSON serialisieren (z. B. mit gson), schlägt die (De-) Serialisierung fehl, wenn diese Klassen verschleiert sind (z. B. von Proguard). Sie müssen Proguard konfigurieren nicht solche Klassen zu berühren - es ist die einfachste nur einzelne Paket mit allen von ihnen zu geben

— jmuet

6

Normalerweise möchte ich Folgendes haben:

bin (Binärdateien)
doc (Dokumente)
inf (Information)
lib (Bibliotheken)
res (Ressourcen)
src (Quelle)
tst (Test)

Diese mögen als unkonventionell angesehen werden, aber ich finde es eine sehr schöne Art, Dinge zu organisieren.

"Diese können als unkonventionell angesehen werden" Sie sind übrigens tatsächlich unkonventionell und schlecht ...

— Mahieddine

2

@ Mahieddine Warum hältst du sie für schlecht?

— Thomas Johannesmeyer

Nun, das habe ich nicht gesagt, aber hier sind einige meiner Gedanken: Ihre Testklassen sind Quellcode, daher sollte das Verzeichnis "tst" (die meisten Leute kürzen den Test übrigens nicht ab) ein Unterverzeichnis von src sein (z. src "wird zu" src / main "und" tst "wird zu" src / test "). Auch "inf" scheint Inhalte zu enthalten, die in "doc" enthalten sein könnten.

— Nico Wawrzyniak

6

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

— Raj
quelle

3

So wie ich normalerweise meine Ordnerhierarchie habe

Projektname
- src
- Behälter
- Tests
- libs
- docs

— pdeva
quelle

1

Eine andere Möglichkeit besteht darin, die APIs, Dienste und Entitäten in verschiedene Pakete aufzuteilen.

— Deepak Patankar
quelle