Überlegungen zur Modularität eines Projekts und Pluginartige Programmierung

TheDarkRose

Gesperrter Benutzer
Hallo

Spiele schon seit einiger Zeit mit den Gedanken eine Art Groupware/Projektmanagement in Java EE zu entwickeln. Was es können soll, steht zumindest schon im Grundgedanken fest. Nun stelle ich mir aber die Frage nach der Modulisierung der einzelnen Teile, sprich in wie weit ich das ganze in die einzelnen Eclipse Projects zerlegen soll.
Gedacht habe ich mir das so (Hier als Beispielname derp verwendet). ein derpEAR Project welche dann alle module zusammenbindet.
Für die einzelnen Module (News, Projekte, Aufgaben, etc.) jeweils ein derpModuleEJB und derpModuleEJBClient Projekt, mit den Packages com.abimus.derp.module.ejb/.eao/.dto/.interfaces
Bei der derpWAR bzw. dem derp (App Client) denke ich muss ich wieder alles in einem Projekt lassen, da ja hier die Präsentation Zusammenhängt. Einzelne Klassen die einen Modul zuzuordnen sind würde ich trotzdem in die Packages com.abimus.module.web/.client packen.
Hierbei ist module in den Project und Packages Names als Platzhalter für den jeweiligen Modulnamen zu betrachten ist.
Ist diese Modularisierung ausreichend oder sollte ich noch feiner splitten. Oder ist das schon übertrieben?

Weiteres habe ich mir gedacht, das ganze Pluginartig programmieren, wenn sowas möglich ist. Soll ja Nutzer der Software dann geben, welche nicht alle Parts der Software benutzen wollen, oder was zusätzlich haben wollen. Wie lässt sich sowas für JavaEE ähnlich dem Eclipse Plugin System realisieren? Ich mein, man kann ja im z.B. Glassfish Server beliebig die Module deployen, aber ich packe ja hier alles in eine .ear Datei, die dann deployt wird. Lässt sich das ganze auch anders lässen außer ein repacking der .ear vom Nutzer selbst aus?
 
D

DasRegtMichAuf

Gast
Hi,

totaler Blödsinn. Das ganze nennt sich Design by Contract und hat im Java EE Bereich nichts zu suchen! Wenn du Modulartig deine Anwendungen aufbaust, kannst du deine Entities nur innerhalb der Modulen Verwalten aber nicht außerhalb d.h. du kannst keine Beziehungen zueinander aufbauen. Dann kannst du auch gleich auf JPA/Hibernate verzichten und kannst den ganzen Mist wieder mit nativen Connection/ResultSet aufbereiten!!!

Gerade wenn du schreibst: "Einzelne Benutzer....". Dann sind eigentlich alle deine Module von dem Benutzer abhängig! Aber du kannst innerhalb der Module den Benutzer nicht mit verwalten. Dann musst du eine Integrationsschicht zusätzlich programmieren wo diese zusammenhänge hergestellt werden d.h. aus Perfomance/Wartbarkeit/Skalierbarkeit ein absoluter Alptraum!!!

"Module" machen nur Sinn wenn sie einen einheitlichen Geschäftsbereich wiedergeben z.B. ein Waren-Management-System oder ein DWH...

Eine Frage: Woher hast du die Idee? Wird das irgendwo gelehrt? Weil ich wurde gerade beauftragt ein Projekt zu refactoren wo genaus so ein blödsin umgesetzt wurde! Das angebliche "Datenbank-Model" ist eigentlich nur ein Ansammlung von zusammenhangslosen Tabellen! Die Perfomance ist grauenvoll und die Daten sind durch die fehlen Integritätsedingung teilweise falsch!
 

TheDarkRose

Gesperrter Benutzer
Juhuuu, eine Antwort :)

Hi,

totaler Blödsinn. Das ganze nennt sich Design by Contract und hat im Java EE Bereich nichts zu suchen! Wenn du Modulartig deine Anwendungen aufbaust, kannst du deine Entities nur innerhalb der Modulen Verwalten aber nicht außerhalb d.h. du kannst keine Beziehungen zueinander aufbauen. Dann kannst du auch gleich auf JPA/Hibernate verzichten und kannst den ganzen Mist wieder mit nativen Connection/ResultSet aufbereiten!!!
Aber ich könnte alle Entities in ein eigenes Eclipse JPA Project verfrachten, oder?

Gerade wenn du schreibst: "Einzelne Benutzer....". Dann sind eigentlich alle deine Module von dem Benutzer abhängig! Aber du kannst innerhalb der Module den Benutzer nicht mit verwalten. Dann musst du eine Integrationsschicht zusätzlich programmieren wo diese zusammenhänge hergestellt werden d.h. aus Perfomance/Wartbarkeit/Skalierbarkeit ein absoluter Alptraum!!!
Wie meinst du das, eine Integrationsschicht? Redest du von Data Transfer Objects die zwischen Client App und Java EE Server übertragen werden?

"Module" machen nur Sinn wenn sie einen einheitlichen Geschäftsbereich wiedergeben z.B. ein Waren-Management-System oder ein DWH...
Das ist etwas grob-granularer als ich mir gedacht habe, aber eigentlich ganz gut. Oder reicht es die gewünschte Granularität (um die Übersicht zu bewahren) rein mit den Packages in einem EJB Project herzustellen?

Eine Frage: Woher hast du die Idee? Wird das irgendwo gelehrt? Weil ich wurde gerade beauftragt ein Projekt zu refactoren wo genaus so ein blödsin umgesetzt wurde! Das angebliche "Datenbank-Model" ist eigentlich nur ein Ansammlung von zusammenhangslosen Tabellen! Die Perfomance ist grauenvoll und die Daten sind durch die fehlen Integritätsedingung teilweise falsch!
Nein, das wird nirgendswo gelernt. Alles was ich bis jetzt übers programmieren weiß, musste ich mir selber beibringen (außer SPS ;) ). Erste Berührungen mit Java EE hab ich anhand dieses Tutorials gemacht: An Eclipse / GlassFish / Java EE 6 Tutorial » Programming
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
B Online Status eines Benutzers abrufen Allgemeines EE 27
WetWer Aufbau eines JSP EE Projekts Allgemeines EE 4
O JSF Login mit Hilfe eines Sharepoint 2013 Users Allgemeines EE 4
R Mehrere Bilder gleichzeitig bzw. dynamisch eines Objektes speichern Allgemeines EE 2
R JPA Problem beim Speichern eines Users Allgemeines EE 2
S Aufruf eines EJBs aus einer nativen Java-Applikation Allgemeines EE 1
O JBoss und die Einbindung eines externen JAR Allgemeines EE 10
DStrohma Innerhalb eines Webservices die reine SOAP Nachricht ausgaben Allgemeines EE 2
A Probleme bei der Einbindung eines Liferay Portalserver (Glassfish) Allgemeines EE 7
S Validierung eines Datums Allgemeines EE 3
M Frage zum Einsatz eines loggers Allgemeines EE 2
G Rollen eines Benutzers ermitteln Allgemeines EE 16
M Wie zeige ich Attribute eines Objekts innerhalb einer JSP an Allgemeines EE 2
isowiz Positionierung innerhalb eines <h:commandLink> Allgemeines EE 7
D Controller-Klassen eines Servlets testen mit JUnit Allgemeines EE 3
S Struts - Direktaufruf eines URL verhindern Allgemeines EE 11
J init-Methode eines Servlet ausführen ohne vorherigen request Allgemeines EE 2
G Servlet beim Absenden eines Formulars aufrufen Allgemeines EE 11
M Builden eines Web Service Projekts scheitert Allgemeines EE 6
B Ursprung eines Requests Allgemeines EE 5
F Aufbau eines Content managment systems Allgemeines EE 8
M Pfad eines Bildes angeben? Allgemeines EE 1

Ähnliche Java Themen


Oben