Source-Verzeichniss/Packages in EJB3/JEE Projekten

Hallo Java-Experten,

ich bin nicht so glücklich mit unserer Source-Verzeichnis-Struktur in EJB3/JEE Projekten. Hat da jemand eine gute Idee?

Es gibt bei unseren Projekten meist für jedes Modul meist Java-Klassen aus den folgenden Bereichen:

  • Entity-Beans (die auch als Value-Object verwendet werden)
  • Domain-Objects
  • Session-Beans
  • Facade-Interfaces (für die Session-Beans)
  • Swing-Client
  • Web-Client

Nicht immer gibt es natürlich Klassen in allen Bereichen, wenn auch oft.

Um die Ant-Buildfiles generisch zu halten, gibt es unter jedem Modul für die o.g. Bereiche je ein Unterverzeichnis, also auch Unter-Packages. In das jar für den Swing-Client kommen so immer entities/*, domain/*, facade/* und swing/*. Ähnlich für den App-Server und Web-Server.

Aber oft ist dann nur eine einige Datei in so einem Verzeichnis, was irgendwie „unschön“ ist.

Alle Java-Dateien eines Moduls in ein Package ohne Unter-Packages hat aber auch zwei Nachteile:

  1. Die Dateien/Klassen für verschiedene Clients (z.B. für SOAP, JSF, Swing) würden bunt gemischt werden.

  2. Einige Module sind auch sehr groß und haben zig Facade-Interfaces, mehrere Session-Beans etc.

Hat jemand eine gute Lösung dafür?

Alles Gute wünscht
… Michael

Moin Moin,

falls mal jemand dasselbe Problem hat, ich habe das nun so gelöst:

…/MODULE/

  • Entity-Beans
  • Facade-Interfaces
  • Domain-Objects

Das sind also Interfaces und Klassen, die in mehreren Schichten benötigt werden.

…/MODULE/ejb/

  • Session-Beans
  • MessageDriven-Beans
  • Implementations-Hilfsklassen

Hier also die Implementation der EJBs für den Server.

…/MODULE/swing/

  • Swing UI Klassen

Hier die Swing-GUI Implementation.

Parallel dazu werden dann die Implementationen andere Clients (z.B. JSF) abgelegt.

MODULE ist ein Platzhalter, ersetzt durch die jeweiligen Modulnamen. Wobei jedes Modul nur über die Interface-Klassen aus den jeweiligen Modul-Hauptverzeichnissen kommuniziert.

Alles Gute wünscht
… Michael