Package Struktur

[ARadauer]

Jetzt muss ich mal fragen, wie ihr eigentlich heure packages organisiert.
Man sieht es ja sehr oft, das die packages technisch geordnet sind. Gui Elemente in ein Package, Modell Klassen in ein Package, DAOs in ein Package, controller usw....

Ich mach das eigentlich immer mehr fachlich. Also gui, model, conroller dao für zb benutzerverwaltung ein packate, produktverwaltung in ein package usw...

wie macht ihr das?

 

[BjörnBu]

Zuerst wird nach layern innerhalb der Applikation geteilt. Wie genau hängt von der Art der Anwendung ab.

Beispiel Web/EE-App:
persistence (nur konkrete implementierung der repositories, bzw dao je nach wording)
domain (entitäten, value objekte, services, spezifications und co.)
web (controller, form beans etc)

je nach umfang wird dann natürlich weiter geteilt. Um das standart Beispiel web-Shop nochmal zu missbrauchen: domain wird in shop und user geteilt.

Weiterhin in den packages liegen erstmal i.d.R. interfaces. konkrete Klassen sind (wenn es viele sind) in 'nem extra impl package.

Ich trenne eigentlich immer irgndwie nach concern. erst nach layer, dann fachlich, dann ggf noch technisch. Mehr als 10 Klassen in 'nem package hab ich nur in Ausnahmefällen.

 

[didjitalist]

Ich trenne eigentlich immer irgndwie nach concern. erst nach layer, dann fachlich, dann ggf noch technisch. Mehr als 10 Klassen in 'nem package hab ich nur in Ausnahmefällen.

Mach ich ebenso. Allerdings spare ich mir generische packages wie "impl" für konkrete Implementierungen.

Ich finde es wichtig, dass Klassen, die zu einer gewissen Funktionalität gehören, sich auch alle in demselben package befinden. Verteilt sich diese Funktionalität auf verschiedene layer, so finden sich dieselben package Namen auch in den unterschiedlichen layer packages wieder.

Das heisst, es gibt eine package Struktur direkt an der Quelle (Datenbank o.ä.), eine für den service layer, eine für die business logic und eine für konkrete Applikationen.

Wobei diese grundsätzlich Struktur für manche Anwendungen auch über den Haufen geworfen werden kann. Man muss sie nicht mögen, aber die database driven applications gibt es halt immer noch. Wunderschöne Verwurstung von DB Zugriffen und Geschäftslogik. Schnell und solide

 

[maki]

persistence (nur konkrete implementierung der repositories, bzw dao je nach wording)

DAO != Repository

Daos sind low level (CRUD), Repositories sind high level, ideal um Domainobjekte andere Domainobjekte zu finden/ändern zu lassen, aber eben auf einen höheren Abstraktionebene als Daos, mehr die Business Operation als die primitiven DB Operationen.

Domain und Services kann man trennen.