Best Practice Fragen zu Projektstruktur einer Datenbank-Abfrage-App (MVC)

[//shad0wC0der]

Hallo zusammen,

ich tue mich mit der allgemeinen Projektstruktur meiner App etwas schwer und hoffe hier entsprechende Lösungsansätze (Denkansätze) zu bekommen.

Die App ist eine in JavaFX erstellt Oberfläche mit diversen Eingabefeldern und Optionen. Daraus wird eine Datenbankabfrage erstellt und das Ergebnis dann in einer Tabelle angezeigt. Ebenfalls besteht die Möglichkeit das Ergebnis in ein Excel File zu speichern.
Hier habe ich das MVC-Pattern als guten Lösungsansatz auserkoren und eine erste grobe Package Struktur etwas so erstellt:

de.meinprojekt.model
de.meinprojekt.controller
de.meinprojekt.view
de.meinprojekt.main

Ich bin mir jetzt allerdings mehr als unsicher wo ich gewisse Klassen unterbringen soll, ob ich z.B. noch weitere Packages nutzen sollte oder Sub-Folder innerhalb dieser Packages.

Konkret geht es hier z.B. um die Service und Task Klassen die mir das Resultset liefern, die Daten in eine Tableview schreiben oder in ein Excel-File speichern.
Gehören diese Dinge alle in die Controller Struktur oder eher zum Model?
Auch Dinge die z.B. nur das Aussehen der App steuern (z.B. Darkmode / Lightmode).

Ich hoffe mein Problem ist verständlich dargestellt und es findet sich jemand der mir hier unter die Arme greifen kann.

Danke schonmal und Gruß
z

 

[Maliko]

Also ich würde sagen alles was die Geschäftslogik abbildet gehört ins Model. Die Klassen, welche für die Abbildung der Datenbank zuständig sind und dann nachher die Daten vorhalten, würde ich als Entities noch einmal separat abspeichern.

Alles was sich um die Anzeige in den Views kümmert, gehört in den Controller (wie z.B. auch die Steuerung für Dark-/Lightmode)

 

[Robert Zenz]

Also rein technisch gesehen gehoert Logik nicht ins Model, weil das Model ist das Model und hat keine Logik. Aber wie bei so vielen Dingen, ist es immer eine relative Frage. Ich persoenlich sehe ich das immer so das ich zwei grosze Bereiche in meinen Applikationen haben. Einmal das "Backend", Logik, Model, alles was man an Logik und sonstigem braucht, und dann ist da was auch immer es fuer eine Schnittstelle nach Auszen gibt, also GUI oder API oder was auch immer.

Ich bin mir jetzt allerdings mehr als unsicher wo ich gewisse Klassen unterbringen soll, ob ich z.B. noch weitere Packages nutzen sollte oder Sub-Folder innerhalb dieser Packages.

Sub-Pakete solltest du auf jeden Fall verwenden wenn es Sinn macht. Also wenn du unterschiedliche Bereiche hast solltest du die Pakete dann auch entsprechend anlegen und aufbauen um dies widerzuspiegeln.

Konkret geht es hier z.B. um die Service und Task Klassen die mir das Resultset liefern, die Daten in eine Tableview schreiben oder in ein Excel-File speichern.

Das klingt fuer mich vermischt. Etwas das Daten liefert ist Logik/Backend/Controller, etwas das Daten anzeigt oder hinausschreibt ist GUI/View. So in der Art:

de.meinprojekt
 |-controller
 |  \-DataProvider (Interaktion Datenbank und so weiter...)
 \-view
    |-ExcelFileService (Schreiben in eine Datei)
    \-GUI (Dem Benutzer anzeigen)

Also deine Ansichten oder Schnittstellen nach Auszen, egal was diese machen, verwenden nur deine Logik um die Daten zu erhalten und diese dann anzuzeigen.

Auch Dinge die z.B. nur das Aussehen der App steuern (z.B. Darkmode / Lightmode).

Das ist jetzt die Frage wie die Trennung genau aussehen soll. Wenn du "pures" MVC machst, gehoert das alles in den Controller welcher zur View gehoert. Ich persoenlich halte es aber fuer die Verantwortung der View/GUI wie diese auszusehen hat. Ich denke aber da gibt es einige unterschiedliche Standpunkte was Sinn macht und was nicht. Die eigentliche Idee hinter MVC ist ja dass die Views keinerlei Logik halten sondern alles in den Controllern liegt. Das ist meiner Erfahrung und Meinung nach nur sehr bedingt zielfuehrend, weil es sehr, sehr selten ist dass die Trennung wirklich Sinn macht. Meistens sind die View/Controller Paare ohnehin so stark gekoppelt dass man die View nicht einfach so austauschen kann und beide ein harte gekoppeltes Paar sind.

Aber fuer MVC selbst ist es so dass die View keine unmittelbare Logik enthaelt und sich der Controller um alles kuemmert.

 

[thecain]

Also rein technisch gesehen gehoert Logik nicht ins Model, weil das Model ist das Model und hat keine Logik.

Also ich hab MVC so gelernt, dass die Geschäftslogik im Modell sein soll.

 

[Robert Zenz]

Also ich hab MVC so gelernt, dass die Geschäftslogik im Modell sein soll.

Kann gut sein dass ich das gerade mit etwas anderem gemischt habe...oder gerade bei einer anderen Definition von Modell war.

 

[thecain]

Kann gut sein dass ich das gerade mit etwas anderem gemischt habe...oder gerade bei einer anderen Definition von Modell war.

Ja, Modell ist ein Begriff, der ohne Kontext fast alles bedeuten kann.

 

[yfons123]

da du mit javafx arbeitest musst du deine Struktur anpassen falls du mit maven arbeitest UND mit fxml arbeiten willst
falls du die GUI programmieren willst also mit klassen dann ist das folgende komplett wurscht

"musst" im relativen sinne.. natürlich muss man nicht

der FXMLLoader schaut im aktuellen Ordner und in dem Resource ordner der Parallel dazu existiert zb

/main
    /source
        /bob
            LoginController.java
    /ressource
        /bob
            Login.fxml

hier würde der FXMLloader in dem LoginController in dem Pfad

/main/source/bob/Login.fxml

zuerst nachschauen ob es da eine solche Datei gibt und wenn nicht schaut der ZUSÄTZLICH

/main/resource/bob/Login.fxml

auch noch hier nach weil das der "Parallele" Ordner im Vergleich zu dem Source Ordner ist


das ist ein Javafx spezielles Feature was man bei einem Code Review erwarten würde.
Der Hintergedanke ist der ... warum soll die fxml rum gurken in dem Source ordner ... fxml ist eine Resource und da hat sich oracle das feature ausgedacht und das funktioniert ziemlich gut

Falls du die Javafx View mit code Programmierst und nicht mit fxml sollte die View in den Source ordner
Als Hinweis: hole dir einen scenebuilder.. da oracle mit seinen accounts und lizenzen jeden auf den sack geht wüürde ich den empfehlen

Scene Builder - Gluon

Drag & Drop,Rapid Application Development. Download Now Integrated Scene Builder works with the JavaFX ecosystem – official controls, community projects, and Gluon offerings including Gluon Mobile, Gluon Desktop, and Gluon CloudLink. Simple Drag & Drop user interface design allows for rapid...

gluonhq.com

der ist einfach zu bedienen und es gibt keinen Account Verfikations Bullshit Bingo von Oracle

 

[thecain]

der FXMLLoader schaut im aktuellen Ordner und in dem Resource ordner der Parallel dazu existiert zb

Wie kommst du denn auf die Ideen? Also ist zwar eine spannende Theorie, wie das funktionieren könnte, ist aber nicht so.

Nachdem maven die Sourcen kompliert hat, liegt das alles unter /target/classes und zwar sowohl die .class files, als auch alle Ressourcen. Da brauchts kein "Feature" vom FXML Loader

 

[yfons123]

Wie kommst du denn auf die Ideen? Also ist zwar eine spannende Theorie, wie das funktionieren könnte, ist aber nicht so.

Nachdem maven die Sourcen kompliert hat, liegt das alles unter /target/classes und zwar sowohl die .class files, als auch alle Ressourcen. Da brauchts kein "Feature" vom FXML Loader

https://www.java-forum.org/thema/javafx-fxml-und-scenebuilder.198815/post-1321357

"falls noch jemand daran zweifeln sollte"

Es überrascht mich dass @KonradN es liked obwohl er es selber ausprobiert hat und bestätigt hat dass es so funktioniert

 

[thecain]

Ich sage nicht, dass es nicht funktioniert. Aber deine Begründung warum es funktioniert ist falsch.

 

[KonradN]

Hier bitte etwas aufpassen und genau unterscheiden:
a) Zur Entwicklungszeit nutzt man den Scene Builder. Dieses Tool bietet eine sehr gute Integration vom Controller und man kann bei der Auswahl der aufzurufenden Methoden die Methoden des Controllers in Drop Down Menus auswählen
==> Dies funktionierte bei meinen damaligen Tests nur, wenn der Speicherort der fxml Datei dem package des Controllers entsprochen hat. (Das dürfte aber ein Bug sein, der ggf. in neuen Version behoben sein wird!)

b) Zur Laufzeit werden hier Dinge geladen. Hier kommt der FXMLLoader ins Spiel. Hier gibt es dann keine src Verzeichnisse mehr sondern nur noch einen Classpath und über den Classloader wird dann der Controller geladen. Dabei spielt das Package keine Rolle mehr. Und der Speicherort ist auch egal - hier wird mit einer URL die Datei geladen - der Speicherort spielt also keine Rolle!

Also immer gut aufpassen - ersteres ist als nur Scene Builder / Entwicklungszeit und da gibt es den Classpath nicht. Und das Zweite ist FXMLLoader / Laufzeit - da gibt es diese src Ordner nicht mehr sondern nur eine (beliebige) URL für das fxml und einen Classloader, der den Controller vom Classpath lädt.

Also man kann die Dateien beliebig legen. Dann funktioniert der SceneBuilder auch (mit kleinen Abstrichen wegen dem Bug).

 

[yfons123]

hier wird mit einer URL die Datei geladen

ich muss aber dann gar keine URL mehr eintippen

zb

FXMLLoader("bob.fxml");

obwohl bob.fxml im resourcen ordner ist wird gefunden

wenn die datei woanders ist muss ich den Pfad richtig angeben

 

[KonradN]

ich muss aber dann gar keine URL mehr eintippen

Du musst dem FXMLLoader im Programmcode eine URL übergeben. Da wird auch in der Regel nichts eingetippt.

Und nein - FXMLLoader hat keinen Konstruktor, der einen String nimmt. Was Du vermutlich im Kopf hast ist etwas wie:
new FXMLLoader(getClass().getResource("bob.fxml")
und hier wird die bob.fxml nicht im Resource Ordner gefunden. getClass.getResource nutzt den Classloader um die Ressource auf dem Classpath zu suchen. Der Classloader gibt eine URL zurück. Der FXMLLoader bekommt also eine URL.

Und der Ablauf ist, wie es @thecain schon etwas gesagt hat:

• Beim Build Prozess werden die *.java Dateien übersetzt und landen dann im Zielverzeichnis.
• Die Resourcen werden vom Build Prozess in das Zielverzeichnis kopiert.

Bei maven ist das Zielverzeichnis target/classes

Und beim start werden die Daten dann z,B. von dort genommen. Oder der Build Prozess baut daraus ein JAR oder es wird ein Image gebaut oder .... - egal wie: Die Dateien (.class, .fxml, ...) sind am Ende im Classpath.

 

[//shad0wC0der]

Vielen Dank für die teils ausführlichen Antworten und auch aus den Diskussionen die hier entstanden sind kann ich das ein oder andere rausziehen!
Für diejenigen die es interessiert, ich arbeite mit dem SceneBuilder von Gluon und erstelle das Projekt ohne Maven.