Konzeptfrage: Applicationserver, oder nicht?

[MarkusM]

Hallo zusammen,

ich hoffe ich habe hier die richtige Stelle des Forums gefunden um meine Frage zu platzieren.

Mein mittel- bis langfristiges Ziel ist es, eine Client-Server-Anwendung mit Datenbankanbindung zu schrieben, auf die bis zu 30 Personen aus dem lokalen Netzwerk zugreifen sollen. Wenn man so möchte, soll es eine Art CRM-System werden. Für mich ist das ein Riesenprojekt und ich bin mir durchaus bewußt, dass ich noch viel Zeit investieren muss, um mein Ziel zu erreichen - was auch kein Problem darstellt.

Was mich zur Zeit umtreibt, ist das technische Konzept um zum Ziel zu kommen. Was ich auf jeden Fall möchte, ist die Aufteilung nach Client-Server-Datenbank-Prinzip. Die Frage ist nur, welcher Mittel bediene ich mich da am sinnvollsten?

a) Verbindung des Client zum Server mit RMI bzw. SIMON? Kommunikation des Servers mit Hibernate zur Datenbank?

b) Einsatz eines Applicationservers? Wenn ich es richtig verstanden habe würde z.B. bei der Benutzung von JBoss die komplette Kommunikationsgeschichte (Client-Server) programmiertechnisch wegfallen, oder? Auch die Kommunikation mit der Datenbank wird durch die implementierten Funktionen des Applicationservers abgebildet, oder arbeitet der auch mit Hibernate?

Es sind natürlich alles sehr komplexe Themen, die viel Zeit zur Einarbeitung erfordern, das ist mir klar. Mir fehlt jedoch soetwas wie der "rote Faden", mit welchen Mitteln eine solche Anwendung realsiert werden sollte/könnte. Daher würden mir konkrete Empfehlungen von erfahrenen Programmierern helfen.

Ich freue mich wirklich über jede Anregung.

Viele Grüße

Markus

 

[Ullenboom]

Mit Java EE bohrt man gleich richtig große Löcher. Wie greifen die Nutzen denn auf die Dienste zu? Mit einer Web-Anwendung? Oder etwa mit Swing/SWT/JavaFX und Rich-Clients? Das würde das Design schon etwas beeinflussen.

Im Prinzip hat man bei Java EE-Apps eine RMI/REST/SOAP-Fassade, dahinter die EJB-Services für die Business-Logik. Die Services können mit JPA auf die DB zugreifen. Hibernate "sieht" man (im Idealfall?) nicht, das ist "nur" ein JPA-Provider. Im Fall von GlassFish wäre es auch Eclipse Link, die Referenz-Implementierung für JPA 2.x. JBoss nutzt Hibernate als PJA-Provider, ja, aber durch die JPA-API ist das (im Idealfall) egal.

 

[MarkusM]

Die Clients würde ich mit JavaFX realsieren.

Ich bin halt hin und her gerissen. Der einfachste Weg wäre wahrscheinlich alles in den Client zu packen. Allerdings sind dann dort auch die ganzen Benutzerdaten inkl. Datenbankzugriff enthalten. Das finde ich nicht so wirklich toll.

Andererseits möchte ich nicht direkt damit anfangen "richtig größe Löcher" mit JavaEE zu bohren. Im Zweifel kann ich das eh nicht, da ich für die EE noch sehr viel lernen muss. Mir ist allerdings klar, dass ich so oder so noch viel Zeit da rein investieren muss, was für mich auch ok ist (Zeitdruck gibt es zum Glück keinen - es ist eher so ein Projekt für mich ).

Wie würdest Du (und natürlich auch andere) Dich denn da rantasten? Was macht Sinn für ein solches Projekt zu lernen und in welcher Reihenfolge? Java, Java, Java ist klar. Nur dann?

Es ist mir auch bewußt, dass es kein allgemeingültiges "Konzept" gibt, aber vielleicht kann mir einer mal nur ganz, ganz grob skizzieren mit welchen Mitteln er das genannte Projekt angehen würde.

Viele Grüße

Markus

 

[Ullenboom]

Ich denke, man kann in unterschiedlichen Iterationen an das Problem drangehen. Als erstes ist ein Fat-Client denkbar. Intern sollte die Realisierung schon so sein, dass View vom Backend klar getrennt sind, dann lässt sich das später einfacher aufspalten.

Idee:

1. Schreibe Services, die deine Business-Logik abbilden und DB-Operationen über Hibernate realisieren. Mit javax.inject zu arbeiten (Guice oder Spring) wäre gut.
2. Habe in paar Testfälle, die dir "beweisen", dass die Services auch ohne Gui gut funktionieren.
3. Schreibe für die Gui-Schicht Fassaden und greife dann per JavaFX -- oder was du für die View-Schicht nehmen möchtest -- auf die Services zu. Hier gibt es auch noch sehr viel zu machen, etwa MVP-Aufspaltung, aber das ist Design auf der View-Schicht. Ist noch mal 'ne andere Nummer.

 

[MarkusM]

Vielen lieben Dank! Dann höre ich mal auf Deinen Rat und fange mit einem Fat-Client an. Wenn ich hier auf eine saubere interne Trennung der View vom Backend achte, kann ich später versuchen die Sache zu trennen.

Hibernate und Dependency Incection werde ich mir jetzt erstmal genauer anschauen und versuchen die BL und DB-Geschichte sauber aufzusetzen. Dann habe ich zumindest erstmal einen Anfang, weiter Probleme kommen bestimmt von ganz alleine

Mit JavaFX habe ich ein sehr gutes Gefühl für die GUI, aber das ist erst der letzte Schritt. Aus meiner Sicht zwingt es einem das MVC-Konzept geradezu auf.