Praktische Anwendung des MVC

[DaBe1812]

Hi,

ich habe dieses Jahr evtl. die Möglichkeit mein Projekt neu zu strukturieren. Ich habe mittlerweile mehr über das MVC gelesen und irgendwie fehlt mir so ein wenig Kontext beim Model-Teil.

Also ich habe eine normale JPA Entity, in der habe ich alle Felder und deren Getter und Setter-Methoden und zusätzlich noch Methoden, die in die Entität gehören.
Dann habe ich eine Klasse, in der ich alle Methoden habe, um Daten aus der Datenbank zu dieser Entität in allen möglichen Abfragen bereit zu stellen.
Und hier habe ich laut allen Examples ja schon einen Fehler, oder? Jedes Example hat dafür ein DAO-Interface und da drin sind immer nur solche generischen Funktionen, wie getById oder getAll. Außerdem verstehe ich nicht den Sinn von einem Interface, wenn man dazu nur eine einzige Implementierung hat. Oder macht es Sinn die Implementierungen auf zu teilen?
Als konkretes Beispiel habe ich eine Parameter Entität, dort sind alle Konfigurationen der Anwendung gespeichert. Diese sind aber nach "Funktion" unterteilt. Also habe ich z.B. ein MailConfig Objekt, dieses benötigt nur die Parameter vom Typ 'Mail'. In meiner Klasse zur Datenbeschaffung habe ich also eine Funktion, die getMailConfig heißt und ein Objekt vom Typ MailConfig zurück gibt.
Irgendwie fühlt sich das aber falsch an.

Außerdem habe ich in meinem letzten Post zu Maven bei @LimDul gesehen, dass er alles, was Entitäten betrifft in einem Modul hat. Finde ich gut, würde ich auch gerne so machen, aber was gehört dann alles dort rein? Also alles, was @Entity ist selbstverständlich, aber kommen dann nur die DAO-Interfaces rein, oder auch die Implementierungen? Also um beim MailConfig-Beispiel zu bleiben:
Parameter-Entität kommt auf jeden Fall rein
Dann ein DAO inclusive Implementierung, welches eine Liste von Parametern liefert und die Parameter-Art als Aufrufparameter bekommt.

Und die Methode, die aus einer Liste von Parametern ein MailConfig-Objekt macht, die kommt dann zu den Geschäftslogiken?

 

[KonradN]

Ich versuche mal zu ein paar Dingen meine SIchtweise zu geben.

Außerdem verstehe ich nicht den Sinn von einem Interface, wenn man dazu nur eine einzige Implementierung hat.

Ja, wenn das Interface nicht benutzt / geraucht wird, dann sollte es das nicht geben. Das ist aus meiner Sicht ein ganz wichtiger Punkt. An der beschriebenen Stelle kann es aber durchaus Sinn machen, wenn man bedenkt, dass man ggf. ja diverse Datenquellen unterstützen möchte. Da kann also tatsächlich ein Interface Sinn machen um für die Zukunft offener zu sein.

(An der Stelle auch einfach einmal der Hinweis, dass es hier diverse Lösungen gibt, die einem hier alles generieren. Bei Datenbankzugriffen hat man oft immer den gleichen Code und da macht es durchaus Sinn, den selbst zu generieren oder so. Ein Beispiel wäre hier z.B. Spring Boot mit den Repositories.)

Außerdem habe ich in meinem letzten Post zu Maven bei @LimDul gesehen, dass er alles, was Entitäten betrifft in einem Modul hat.

Hier sehe ich es ähnlich wie bei den Interfaces: Überlege, was wirklich Sinn macht. Wozu mehrere Module, wenn Du diese immer nur zusammen verwendest?

An Module und Interfaces gehe ich immer aus Verbraucher Sicht heran. Ich überlege nicht: Ich habe hier etwas gebaut: kann ich da ein Interface bauen? (Das war eine alte Sicht. Bei der Booch Method (Vorgänger zu UML sollte alles ein Interface und ein Controller haben. Da wurden massive Formalitäten aufgebaut die viel zu oft sinnlos waren und die heute aus meiner Sicht auch schlicht gegen das Interface Segregation Principle verstoßen würden.)
Die Frage stellt sich für mich eher, was denn aus der Nutzersicht gebraucht wird. Was für Interfaces werden denn überhaupt gebraucht? Und so auch die Frage: Was für Module werden überhaupt gebraucht?

Wenn Du die Entities auch in anderen Projekten brauchst, dann kannst Du diese z.B. in einem Modul bereit stellen. Dann können auch andere Projekte darauf zugreifen. Aber bleiben wir direkt dabei: Das müssen dann Java Projekte sein, damit die diese jar Datei mit Deinen Klassen nutzen können ... Und wie greifen diese darauf zu? ...
In der Regel hast Du dann heutzutage doch meist REST Services. Und dann macht es mehr Sinn, statt eine Implementierung in einer Sprache eine offene Dokumentation zu haben. Und schon sind wir bei Open API / Swagger. Du hast eine Beschreibung und generierst Dir dann den entsprechenden Code. Und das für eine der vielen verfügbaren Sprachen / Frameworks.

Bei dem Datenbank-Layer sehe ich das recht kritisch. Willst Du da wirklich mit mehreren Anwendungen auf einer Datenbank arbeiten? Das geht und kann sogar Sinn machen für Tools oder so. Wenn etwas nicht stimmt oder so, dann kann man schnell ein Tool darauf aufbauen. Aber macht das wirklich so viel Sinn? Wenn Du um die Datenbank z.B. ein CRUD REST Service legst, dann kannst Du da auch alles machen - mit der gewünschten Sprache über den generierten Client Code (Und sowas muss man bei vielen Frameworks kaum noch selbst bauen. Das wird teilweise auf Wunsch direkt bereit gestellt z.B. Spring Data REST).

Also wichtig ist, dass man die Dinge logisch getrennt hält mit entsprechenden Abhängigkeiten. Dann hast Du die Dinge z.B. sinnvoll in Namespaces aufgeteilt. Eine Aufteilung in Maven Module kannst Du später immer noch machen, wenn Du feststellst, dass Du sowas brauchst. So Du die Abhängigkeiten sauber hast innerhalb Deines Codes (Dependency Inversion Principle wäre hier das wichtige Prinzip von SOLID aus meiner Sicht).

Wenn es zu so einer Abtrennung kommen sollte, dann wird es evtl. notwendig, aus ein paar Klassen ein Interface zu machen und die Klasse selbst wird dann eine Implementation des Interfaces. Aber das ist meiner Meinung nach ein schnelles Update, so man nicht wild an allen möglichen Stellen Instanzen erzeugt hat. Wenn es z.B. per Dependency Injection lief oder man ein Factory Pattern hatte, dann ist es meiner Erfahrung nach sehr einfach.

Und was man hier ggf. auch überlegen sollte: Wird es wirklich gebraucht? Also KISS - Keep It Simple, Stupid!
Daher würde ich nichts zu komplex machen, wenn es nicht wirklich notwendig ist.

Und als letzten, wichtigen Punkt: Evtl. die Architektur überlegen. Wenn Du direkt planst, alles so massiv zu unterteilen, dann ist es evtl. sinnvoll, einmal die Architektur zu überdenken. Microservices kommen mir da als Architektur direkt in den Sinn.
Wenn Du die Notwendigkeit zu so Unterteilungen hast, dann ist evtl. sinnvoll die Architektur zu überdenken. Das muss so nicht richtig sein, aber ich sehe zumindest die Möglichkeit, dass dem so ist.

Und evtl. ganz am Rande: Bei einigen (jedoch kleineren) Projekten habe ich genau den anderen Weg eingeschlagen. Explizit nur ein Maven Projekt und das Frontend-Projekt war dann mit im src Ordner (src/main/web meine ich) und über Maven Plugins wurden npm Aufrufe gemacht, die das web Projekt gebaut haben und src/main/resources/static war das generierte Ziel. Letzteres war evtl. nicht ganz so toll - da hätte ich evtl. besser innerhalb des target Ordners einfügen sollen.

Das einfach einmal als ein paar Gedanken von meiner Seite aus. Ich hoffe, dass diese nicht zu unstrukturiert waren und natürlich sind es nur Anregungen. Da ich die Anforderungen nicht kenne, kann Dein Ansatz evtl. genau so berechtigt sein, wie du es machen möchtest, aber evtl. konnte ich Dir Anregungen geben, diese zu überprüfen und ggf. weitere Recherchen zu machen.

 

[Marinek]

Hi,

Jedes Example hat dafür ein DAO-Interface und da drin sind immer nur solche generischen Funktionen, wie getById oder getAll.

Ja, also zum einen ist es so, dass wenn man wirklich immer nur eine Implementierung hat, und dies auch axiomatisch so ist, dann macht ein Interface natürlich kein Sinn.

Du gibst nun nicht an, ob du sowas wie Spring verwendest. In diesem Fall würde Spring die Implementierung liefern und dann hat man natürlich den Vorteil dass man eine Methode schreibt: findByName() und dann macht Spring den Rest.

Irgendwie fühlt sich das aber falsch an.

Hängt von vielen Faktoren ab. Kann man so pauschal nicht sagen. Üblicherweise würde man heute Dependency Injection verwenden, um dem abzuhelfen.

DAO-Interfaces rein,

DAO Interfaces sind Repositorys in Spring boot. Die habe ich immer seperat.