# Technologie Grundlagen für eine "App"



## nfweld (29. Aug 2017)

Hallo,

zur Zeit bin ich dabei, eine Anwendung zu programmieren, die ein Datenformate lesen, in eine Datenbank importieren und visualisieren kann. Dieses Projekt findet im Rahmen meines Studiums statt und eine der Vorgaben, ist es viel Wert auf gängige Praxis zu legen.

Alle Funktionen der Anwendung sind sehr stark modularisiert.
Beispielsweise ist die Datenbank gekapselt, sodass das Programm auf Daten zugreift, ohne Interesse für deren Herkunft.

Das GUI wird mit JavaFX realisiert. Um Redundanzen im Code zu vermeiden, wurden oft verwendete View Objekte in FXML Dateien mit dazugehörigen Controllern separiert. Aus diesen Modulen wird das UI zusammengebaut.

Durch den wissenschaftlichen Hintergrund & meine fehlende Praxiserfahrung hätte ich einige Fragen zur Realisierung im Professionellen Umfeld:

Wie wird normalerweise die Kommunikation unter den einzelnen Modulen realisiert?
(Stichwort: Google Guava EventBus)

Würde es Sinn machen, für dieses Projekt auf das Spring Framework zurück zu greifen?
(Stichwort: Dependency Injection)

Gibt es andere sinnvolle Frameworks, welche genutzt werden sollten?
(Stichwort: automatisierte Test  usw. )


Vielen Dank schon mal für eure Antworten

Gruß nfweld


----------



## dzim (29. Aug 2017)

Ich bin jetzt nur am Telefon unterwegs, könnte dir aber morgen Mal eine detaillierte Antwort schreiben. Heute keine Lust mehr .

So viel: habe die meisten deiner Themen schon lange, mehrfach und in verschiedenen Konstellationen durch.

Ping mich vielleicht Mal morgen an, dass ich es nicht vergesse...


----------



## lordofdonuts (29. Aug 2017)

Servus,

ich muss dich da vorwarnen, fuer deinen Anwendungsfall gibts tausend Moeglichkeiten und mehr, da werden dir 3 Leute 8 verschiedene Meinungen erzaehlen.

Das vorweggenommen, verstehe ich das richtig? Insgesamt gliedert sich das Projekt in drei Module: Importer, Datenbank, Client-Applikation.

Wird vom Client aus importiert (klassisch mittels "Oeffnen"-Dialog) oder handelt es sich um einen separaten Lauf ausserhalb der Client-Applikation?



nfweld hat gesagt.:


> Alle Funktionen der Anwendung sind sehr stark modularisiert.
> Beispielsweise ist die Datenbank gekapselt, sodass das Programm auf Daten zugreift, ohne Interesse für deren Herkunft.



So ganz stimmt das nicht, dein Programm muss sehr wohl wissen, wo die Daten herkommen 



nfweld hat gesagt.:


> Das GUI wird mit JavaFX realisiert.


Selber schuld 
Ist das eine Vorgabe? Wuerd mir da eher was aussuchen, was im Browser rennt...



nfweld hat gesagt.:


> Wie wird normalerweise die Kommunikation unter den einzelnen Modulen realisiert?
> 
> (Stichwort: Google Guava EventBus)


Es gibt zwei Varianten, entweder zu laesst den Client direkt mit dem Server reden oder du spielst das ueber eine Middleware. Von der Architektur waere das dann so:
Client -> Application Server -> Database
Im Falle einer Webapplikation saehe das so aus
Client -> Web Server -> Application Server -> Database

Jedenfalls ist eine gaengige Methode, bei solchen Applikationen Java Enterprise Beans / JPA zu verwenden. Dort werden quasi die Tabellen abstrahiert (gemappt) und jeder Datensatz kommt als POJO daher. Das ist natuerlich nur die einfachste Variante, mit Session-Driven Beans sind noch ganz andere Sachen moeglich.
Dafuer ist eine Middleware im Sinne eines Application Servers notwendig, der sich um die Beans kuemmert. Beispiel WildFly (frueher: JBoss) oder dessen Referenz-Implementierung Glassfish. Vorteil ist z.B., dass Transaction Handling schon eingebaut ist.
http://docs.oracle.com/javaee/6/tutorial/doc/gijsz.html
http://www.tutorialspoint.com/ejb/

lightweight-Variante waere bei einer ueberschaubaren Anzahl von Tabellen eine Umsetzung der Java Persistence API (JPA).
http://docs.oracle.com/javaee/6/tutorial/doc/bnbpz.html
https://www.tutorialspoint.com/jpa/index.htm

Wenn du das nicht willst, kannst du natuerlich mittels JDBC deine SQL-Statements selbst uebergeben und musst dich halt auch selbst damit herumschlagen, wie du deine Information aus dem ResultSet herauspulst. Davon rate ich ausdruecklich ab.



nfweld hat gesagt.:


> Würde es Sinn machen, für dieses Projekt auf das Spring Framework zurück zu greifen?
> 
> (Stichwort: Dependency Injection)


Kommt drauf an, inwiefern skalierbar die ganze Sache sein soll. Nachdem ich keine Vorstellung ueber den Umfang des Projektes habe, sag ich generell einmal ja, da du von der gruenen Wiese startest. Damit kannst du das vorhin beschriebene JPA direkt abhandeln und hast nicht so einen grossen Overhead wie mit WildFly. Seit Version 3 ist das auch nicht mehr so ein exzessives XML Config gewi... Tohuwabohu.
Fuer sowas sollte man immer in Form einer Machbarkeitsstudie ein paar Alternativen auflisten koennen, damit andere sehen, du hast dich mit dem Thema auseinander gesetzt.



nfweld hat gesagt.:


> Gibt es andere sinnvolle Frameworks, welche genutzt werden sollten?
> 
> (Stichwort: automatisierte Test usw. )


Willst dus alphabetisch oder chronologisch?

Du musst bedenken, zwischen automatisierten Tests einer GUI und funktionalen Tests von serverseitigem Code gibts einen Unterschied. Fuer zweiteres reicht ein JUnit, um eine JavaFX GUI automatisiert zu testen, muss geklaert sein, wie diese grafische Repraesentation genau aussieht, wie auf Eingaben reagiert wird, etc.

Zum Schluss moechte ich erwaehnen, ich habe beruflich mit JavaFX und EJB zu tun. JavaFX war anfangs noch ganz interessant, nur sind uns im Betrieb Inkonsistenzen innerhalb des Frameworks aufgefallen, fuer die dermassen viele Eingriffe notwendig waren, dass der Wartungsaufwand gestiegen, anstatt gesunken ist.

Wenn dieses Projekt eine vergleichweise kleine Sache ist, wo nur Daten angezeigt werden, OK. Gaengige Praxis ist aber, von Rich Client Applications weg zu Web Applications zu gehen. Stichwort Angular2, GWT, Node.js, React, ...

Viel Erfolg.


----------



## mrBrown (29. Aug 2017)

Da die zweite Antwort in die Richtung geht: ist das überhaupt eine auf nem Server laufende Anwendung oder läuft die rein Lokal?


----------



## lordofdonuts (29. Aug 2017)

Das will ich doch schwer hoffen, fuer ein Uni-Projekt mit angeblichem professionellen Anspruch waere das doch sehr mau.


----------



## mrBrown (29. Aug 2017)

lordofdonuts hat gesagt.:


> Das will ich doch schwer hoffen, fuer ein Uni-Projekt mit angeblichem professionellen Anspruch waere das doch sehr mau.


Seit wann heißt professioneller Anspruch denn, dass das ganze in nem fetten Application-Server läuft? 
Grad an Unis dürfte das eher selten der Fall sein...


Dem Großteil deiner genannten Punkte kann ich btw so nicht zustimmen - das ist eher ein sehr eingeschränkter Blick aus genau dem Bereich mit dem zu tun hast.  Für so ziemlich nichts davon braucht man einen Application-Server, grad das schon genannte Spring ist da zu nennen, was das alles kann - sogar ganz ohne auf nem Server zu laufen.


----------



## lordofdonuts (30. Aug 2017)

Dass mit Spring der Overhead wegfaellt steht ziemlich genau so da - oder etwa nicht? Ich finds ja witzig, dass mein erster Satz schon nach gut 30 Minuten schlagend wird 

Und wenn ich nicht weiss, wie gross das ganze am Ende sein soll, geh ich halt mal vom Schlimmsten aus.


----------



## thecain (30. Aug 2017)

lordofdonuts hat gesagt.:


> Dass mit Spring der Overhead wegfaellt steht ziemlich genau so da


Nein, der WildFly Overhead soll wegfallen, welcher für Spring nicht benötigt wird. Spring läuft ja schliesslich nicht in einem EE Container.


----------



## mrBrown (30. Aug 2017)

lordofdonuts hat gesagt.:


> Dass mit Spring der Overhead wegfaellt steht ziemlich genau so da - oder etwa nicht? Ich finds ja witzig, dass mein erster Satz schon nach gut 30 Minuten schlagend wird
> 
> Und wenn ich nicht weiss, wie gross das ganze am Ende sein soll, geh ich halt mal vom Schlimmsten aus.


Du erwähnst doch in keinem Satz auch nur Ansatzweise Spring oder bin ich blind?

Ja bin ich offensichtlich -.-


----------



## lordofdonuts (30. Aug 2017)

nfweld hat gesagt.:


> Würde es Sinn machen, für dieses Projekt auf das Spring Framework zurück zu greifen?
> 
> (Stichwort: Dependency Injection)





lordofdonuts hat gesagt.:


> ... ja, da du von der gruenen Wiese startest. Damit kannst du das vorhin beschriebene JPA direkt abhandeln und hast nicht so einen grossen Overhead wie mit WildFly.



Ich hoff das war nicht irgendwie missverstaendlich - wuerd aber gern mal den OP hoeren, bevor wir uns hier noch gegenseitig erwuergen


----------



## dzim (30. Aug 2017)

Also ich habe auch beruflich mit JavaFX und Spring (primär, unter anderen) zu tun. Wenn du eine Dektopanwendung möchtest und alles in Java schreiben willst, ist JavaFX die einzige Wahl. Swing ist es definitv nicht (mehr) und SWT ist zwar gut, was das Layouting angeht, ist aber auch schon etwas "angestaubt".

Auch wenn ich (immer noch) JavaFX-Fanboy bin, hat @lordofdonuts natürlich recht, dass Web-Anwendungen allein schon insofern besser sind, als dass man ohne Aufwand schnell mal UI-Updates ausliefern kann, ohne den Anwender ein Update aufzudrücken. Denn sonst muss man beginnen, sich über so etwas wie einen Updater im Client gedanken zu machen. Ist zwar auch nichts unmögliches, muss man aber erst mal implementieren/finden/...

Soll es eine Rich Client Application (also JavaFX) werden, würde ich Spring dafür nur aus einem Grund nicht verwenden: Der Start ist etwas träge und daher würde ich für Clientseitige DI Google Guice verwenden. Aber das ist keine Notwendigkeit.

Wenn möglich, würde ich den Client relativ "dumm" gestalten - nur UI-Zeug. Richtige Businesslogik (Berechnungen, Daten, etc.) würde ich wohl auch über einen WebServer mit ReST-Schnittstelle anbieten. Auf diese Weise hast du auch später noch einfach die Möglichkeit, das UI gegen eine andere auszutauschen (Desktop: HTML5/JavaScript + Electron, Web: HTML5/JavaScript, mit den von @lordofdonuts genannten Frameworks).

Den Webserver würde ich mit Spring, konkret mit Spring Boot (denn Spring alleine kannste auch in WildFly oder sonst wo laufen lassen), implementieren. Die DB-Abstraktion erhälst du am besten, indem du dir einen Spring-Service dafür schreibst, was dahinter verwendet wird, ist dann dir überlassen: JPA ist für einfacherer DB-Schemas wahrscheinlich erst einmal das schnellste, ich bin aber irgendwie nicht so 100% Fan davon. Alternativen wären jOOQ (dafür musst du aber einen DB-Server mit "fertigem" Schema haben, von dem aus du mit jOOQ den notwendigen Code zum Zugriff generieren kannst!), oder halt Plain-SQL über JDBC. Das letzte ist mit dem grössten Aufwand, aber auch der grössten Kontrolle verbunden (und: ich mag SQL ).

Du kannst natürlich auch komplett anders rangehen und alles über MQQT laufen lassen (und Client, DB-Access, etc. an dem EventBus anhängen). Das ist architektonisch wahrscheinlich das interessanteste, aber von der Umsetzung her wohl auch das aufwendigste. Jedoch muss ich gestehen, dass ich mit MQQT (und ähnlichen) noch nicht geschafft habe. Am dichtesten darangekommen bin ich bisher wohl über die Cluster-Architektur mit Hazelcast. Aber ich würde die Bälle erst mal flach halten und schauen, ob du mit den bisher beschriebenen Möglichkeiten nicht schon genug Arbeit hast.


----------



## nfweld (30. Aug 2017)

Guten Morgen erstmal,
vielen Dank für die zahlreichen Antworten!
Ich hoffe ich kann hiermit schon mal ein paar Unklarheiten beseitigen. 



lordofdonuts hat gesagt.:


> Das vorweggenommen, verstehe ich das richtig? Insgesamt gliedert sich das Projekt in drei Module: Importer, Datenbank, Client-Applikation.


Das ist grundsätzlich schon mal Richtig so. 
Und gerade die Module Importer und Datenbank sollten leicht mit anderen Modulen erweitert werden können.



lordofdonuts hat gesagt.:


> Selber schuld
> Ist das eine Vorgabe? Wuerd mir da eher was aussuchen, was im Browser rennt...





mrBrown hat gesagt.:


> Da die zweite Antwort in die Richtung geht: ist das überhaupt eine auf nem Server laufende Anwendung oder läuft die rein Lokal?


Hierzu muss ich leider sagen, dass es auch die Möglichkeit geben soll das Programm lokal laufen zu lassen ohne großen Datenbank- und Application Server im Hintergrund und z.B. mit einer SQLite Datenbank.
Damit würde eine reine WebApp auch ausscheiden, oder? Allerdings finde ich den Ansatz einer Hybriden App sehr interessant. Theoretisch könnte ein Server ja auch lokal betrieben werden. 

Wenn ich 


lordofdonuts hat gesagt.:


> Damit kannst du das vorhin beschriebene JPA direkt abhandeln und hast nicht so einen grossen Overhead wie mit WildFly. Seit Version 3 ist das auch nicht mehr so ein exzessives XML Config gewi... Tohuwabohu.


Richtig verstanden habe könnte ich JPA mit Spring auch ohne Application Server nutzen.
Denn WildFly würde für die Anwendung einen zu großen Overhead erzeugen.

Um zwischen einer Hybriden App und eines Rich Client also JavaFX zu entscheiden, muss ich mich noch etwas weiter informieren.

Vielen Dank für die Ausführlichen Informationen!
Um weitere Fragen stellen zu können muss ich mich aber noch etwas weiter in die Themen einlesen.
Bei Weiteren Fragen würde ich dann gerne auf euch zurück kommen. 

Gruß nfweld


----------



## mrBrown (30. Aug 2017)

Ja, du kannst Spring (Boot) ganz ohne irgendwelche Web-Sachen nutzen, und bekommst halt trotzdem alles dazu, wie Dependency Injection und Spring Data.

Man kann den Server auch lokal laufen lassen, aber meiner Erfahrung mit Uni-Projekten nach ist das deutlich zu viel Overhead, da ist eine rein lokale App deutlich einfacher.


----------

