Überlegungen zur Modularität eines Projekts und Pluginartige Programmierung

[TheDarkRose]

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?

 

[DasRegtMichAuf]

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]

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