Package / Architektur

[Generic1]

Hallo,

bin das erste mal zuständig für die Architektur eines Projektes (Klassen, Packageaufteilung). Mir ist klar, dass ein Package eine fachliche Gruppierung oder sogar eine Abbildung einer Domain ist.
Zugegriffen wird auf "das Package" bzw. auf Klassen des Packages über Schnittstellen, d.h. für mich mal Interfaces.
Ich bin gerade dabei für die Persistence ein Package zu definieren. Was mit jetzt nicht ganz klar ist, sind die Service und die DAO - Klassen auch in den einzelnen Packages gekapselt oder sind die Services in einem eigenen Packages.
Hintergrund der Frage ist der, dass ich mal gesehen habe, dass alle Services in einem Package waren und dieses Package dann im Spring Framework als Service- Package angegeben wurde.
Wie ist es eurer Meinung nach richtig?

lg

 

[Generic1]

Aha. weiß jetzt nicht ganz ob die Frage so unverständlich oder schwierig ist?
Wie haltet ihr es generell, gruppiert ihr alles was zusammengehört in einem Package und erzeugt danach eine Schnittstelle zu der Funktionalität des Packages oder macht ihr das irgendwie anders?
Beste Grüße,

 

[maki]

Je nachdem, bei OSGi ist die Sache ganz klar, ansosnten so wie es Sinn macht bzw. wie man etwas ausdrücken möchte, generell sollte man die Interfaces cvon den Implementierungen trennen, deswegen müssen aber nciht alle Service Interfaces in ein einziges package.

 

[Generic1]

So wie es sinn macht hör ich gerne ;-) wenn ich das in der Firma höre mach ich es immer wie ich es will un such mir eine vernünftige Argumentation.
Adam Bliem schreibt z.B.: das man die Zugriffs- Interfaces auf das Package immer im selbem Package haben soll, da die Interfaces ja auch zu der Fachlichkeit des Packages gehören.
Besten Dank für die Antwort,

 

[maki]

Adam Bliem schreibt z.B.: das man die Zugriffs- Interfaces auf das Package immer im selbem Package haben soll, da die Interfaces ja auch zu der Fachlichkeit des Packages gehören.

Wirklich... hast du da einen Link zu?

Adam Bien mag zwar ein Vertriebler/Trainer/Architekt für JEE sein, aber deswegen muss er nicht immer recht haben.
Interfaces von Implementierungen zu trennen ist schon seit sehr langem Best Practice und in OSGi Standard.

 

[Generic1]

Ich schreibs dir am Abend, habs jetzt nicht da,
Da hätte ich aber noch eine Frage zur Trennung, wenn mein "Fachlichkeits- Package"

de.firma.projekt.persistance

heißt (in diesem Package werden alle Zugriffe auf die Datenbank gemacht),
wie kann dann das Package heißen in dem ich die Interfaces gebe bzw. gibt es ein Package in dem ich alle Interfaces reingeben, so in der Art:

de.firma.projekt.interface

oder so in der Richtung?

 

[maki]

Sieh es mal so:
Die ganze Fachlickeit wird über Interfaces definiert, implementierende Klassen sind ncihts weiter als "unwichtige & dreckige" Implementierungsdetails, deswegen kommt in [c]de.firma.projekt.persistance[/c] nur interfaces, die implementierungen nach [c]de.firma.projekt.persistance.impl[/c] oder gar [c]de.firma.projekt.persistance.internal[/c], ltzteres im Falle von OSGi, da werden *.internal.* Packages vom Client gar nciht gesehen.

Persönlich würde ich nie für alle Interfaces die mit Persistenz zu haben nur ein einziges Package verwenden.

 

[Generic1]

Besten Dank, ich hab schon mal einen Überblick bekommen, wie du das siehst, was mir aber nicht ganz klar ist, warum ich die Interfaces nicht in das selbe Package stecke, dann habe ich ja wieder alles zerstreut, die Implementierung und die Interfaces, das bei OSGi ist mir klar, wenn die Implementierung versteckt wird, dann muss man die Interfaces von der Implementierung trennen, Ist das auch bei Projekten wie z.B.: meinem "stink normalem Projekt" üblich, das so zu machen?

Und eine zweite Frage bzgl der Persistance, ich dachte mir bis jetzt immer, ein Package für die Persistance damit man alles kompakt bei einander hat, wie (wie heißen die Packages z.B.) und warum trennst du die Persistance- Schicht auf?

 

[maki]

Ich trenne nciht die Persistenzschicht auf, sondern strukturiere die Packages, sont hätte man bei einer 3 Shcicht Anwendung nur 3 Packages 😉

Vereinfachtes Beispiel:

de.firma.project.presentation.product
de.firma.project.presentation.user

de.firma.project.business.product
de.firma.project.business.user

de.firma.project.persistence.product
de.firma.project.persistence.user

Und ja, bei OSGi (und Spring auch) macht man das immer so dass man die Interfaces von den Implementierungen trennt, in JEE Projekten sollte es imho auch so gemacht werden.

Wie gesagt, verstehe Adam Biens Aussage wohl nicht richtig, aber eigene packages für interfaces und deren Implementierung(en) sind nicht verkehrt.

 

[Generic1]

OK, verstehe, wenn ich das Beispiel weiterführe, schaut's dann so aus!?

de.firma.project.presentation.product
de.firma.project.presentation.product.impl
de.firma.project.presentation.user
de.firma.project.presentation.user.impl

de.firma.project.business.product
de.firma.project.business.product.impl
de.firma.project.business.user
de.firma.project.business.user.impl

de.firma.project.persistence.product
de.firma.project.persistence.product.impl
de.firma.project.persistence.user
de.firma.project.persistence.user.impl

 

[Generic1]

Würde das so korrekt sein, wie ich es bei meinem letzten Thread geschreiben habe?
Besten Dank,

 

[maki]

OK, verstehe, wenn ich das Beispiel weiterführe, schaut's dann so aus!?

de.firma.project.presentation.product
de.firma.project.presentation.product.impl
de.firma.project.presentation.user
de.firma.project.presentation.user.impl

de.firma.project.business.product
de.firma.project.business.product.impl
de.firma.project.business.user
de.firma.project.business.user.impl

de.firma.project.persistence.product
de.firma.project.persistence.product.impl
de.firma.project.persistence.user
de.firma.project.persistence.user.impl

Ja, so in etwa.