[Technik] hsadmin reloaded: Verzeichnisstruktur Quelltexte

[Michael Hoennig]

Moin Moin,

bisher ist mein Code noch auf zwei Projektbäume aufgeteilt:

1. JSP-Views, JSF-Controller, JPA-Ebene
2. Prozessor-Klassen für System-Ebene (für root Kommandos)

Vielleicht macht es Sinn, das noch vor dem Treffen in eine brauchbare
Form zu bringen? Datei würde ich gerne die Funktionsbereiche
zusammenhalten, und in diesen Bereichen jeweils alle Schichten
implementieren. Denn spätestens wenn das Kernsystem steht, wird man auf
diese Weise neue Module hinzufügen wollen. Zudem würde ich die
Unittest-Klassen gerne da raushalten, damit es übersichtlich bleibt.

Vorschlag:

src/META-INF/
   /net.hostsharing.hsadmin/core/(...?)
                           /cust/(...?)
                           /user/(...?)
                           /pacs/(...?)
                           /doms/(...?)
                           /email/(...?)
                           /db/(...?)
                           /...
tst/net.hostsharing.hsadmin/core/(...?)
                           /cust/(...?)
                           /user/(...?)
                           /pacs/(...?)
                           /doms/(...?)
                           /email/(...?)
                           /db/(...?)
                           /...

Also für src und tst zwei separate Bäume. Da drin dann wieder dieselben
Java-Pakete, so dass man auch auf protected- und package-Member zugreifen
kann. Oder doch lieber alles in denselben Baum?

Ob sich unterhalb der Module noch eine Unterteilung lohnt, z.B. nach der
Schicht (Controller, Model, Persistenz, System-Ebene), weiss ich noch
nicht. Das Deployment könnte dadurch erleichert werden, weil man genau
wüsste, aus welchen Unterverzeichnisse man die class-Files in welches
jar-File packen müsste. Oft wird dann aber evtl. auch nur eine Datei in
so einem Verzeichnis/Modul liegen, in anderen Fällen natürlich auch mal
ein Dutzend.

Unter "core" vermute ich schon eine Unterteilung, da ich in dem Bereich
aber bis auf die Basisklassen für die System-Schicht (root-Kommandos)
noch nichts habe, fehlt mir hier noch der Überblick, was genau da noch
kommt. Auf jeden Fall natürlich die Klassen für REST und Hilfsklassen für
die JSF-Controller. 

Ebenfalls ist noch offen, ob (und wenn ja wie) man evtl. sogar pro Modul
ein eigenes "Project" (auch im Eclipse Sinne) bauen könnte, welches
jeweils eine eigene .ear (o.ä.) Datei als Output hat. Und zwar wie man
dann den JSP-Workflow hinbekommt. Wenn das geht, wären die Module noch
deutlicher getrennt und auch leichter auswechselbar. Schon bei den Tests
für die Persistenz-Ebene wird das aber schwierig, weil man da schon fast
für alle Teile eine komplette Datenbank (mit allen Kern-Tabellen)
braucht, und das schon wegen der sehr rigiden Constaints, die Stephan
dankenswerterweise in die Bestands-Basis eingebaut hat.

Alles Gute wünscht
	Michael


-- 
Hostsharing eG | c/o Stilflut | Friedensalle. 120 | D-22765 Hamburg
Registergericht Hamburg, GnR 1007 | USt.-ID-Nr.: DE218602793
vertretungsber. Vorstand: Uwe Müller, Peter Niederlag, Michael Hönnig
phone+fax: +49 700 HOSTSHARING (= +49 700 46787427)
http://www.hostsharing.net | http://www.xing.com/go/invuid/Michael_Hoennig