Frage zum Entwurf / json-Datenmodell

[JanHH]

Hallo,

mal wieder ein Posting von mir nach einiger Abwesenheit..

habe eine Software (JEE6/Webanwendung/postgresql), bei der ein reichlich komplexes Datenmodell als json-String gespeichert wird. Das Datenmodell besteht aus einer Verschachtelung von Objekten einer Reihe von Klassen.

Ich frage mich nun, was besser ist:

a) ein "dummes Modell", welches nur aus "leeren Klassen", die nur properties sowie getter und setter enthalten, besteht, und zusätzlich eine "action"-Klasse(/-Objekt), welches die Funktionen bereitstellt, die notwendig sind, um mit dem Datenmodell zu arbeiten

b) ein "intelligentes Modell", bei dem die Objekte neben den Properties auch selber die notwendigen Methoden beinhalten

a ist eher ein prozeduraler Entwurf, b eher "klassisch objektorientiert", aber bei a wird Modell und Funktion sauberer getrennt (was ja bei Webanwendungen durchaus auch ein Aspekt ist).

Ich bin unentschlossen. Was ist heutzutage der bessere Ansatz?

 

[Tobse]

Ich verstehe noch nicht so ganz, worauf du raus willst. Im allgemeinen oder wenn es speziell drum geht, mit JSON zu arbeiten?

Rein prinzipiell spreche ich mich als überzeugter DDD Entwickler für b) aus. Das jetzt ausführlicher zu begründen macht aber wenig Sinn, ohne zu wisse, worauf deine Frage abzielt.

 

[JanHH]

Hmm.. ich hab, als ich mich in die JEE-Materie eingearbeitet hab, speziell was JPA/Hibernate angeht, gelernt (von einem Freund der da sehr fit drin ist und mir das erklärt hat), dass die model/entity-Klassen "dumm" sein sollen und keine Funktion kapseln, ausserdem dass man da eine allzu fein granulierte Klassenhierarchie unterlässt (weil das die Datenbankstruktur sehr kompliziert machen würde) sondern eher flache, designtechisch nicht unbedingt immer perfekt dem theoretischen Ideal entsprechende Klassenhierarchien baut.

Nun hab ich hier allerdings keine JPA-Entities, sondern ein json-Objekt, insofern ist das sicher nicht 1:1 übertragbar, allerdings ist die Klassenhierarchie auch hier eher simpel gestrickt, um das json-konvertieren nicht unnötig komplex zu gestalten, und die Klassen sind "dumm". Also letztlich dasselbe.

Gibt es gute Gründe, das so beizubehalten, oder ist das im Grunde egal, es hat keinen architektonischen Nachteil, derartige model-Klassen "sauber objektorientiert intelligent" zu gesatlten? Das ist im Grunde die Frage, um die es mir geht. Gibt es irgendeinen guten Grund (ausser anfänglicher faulheit) für diesen Entwurf (Variante a).

 

[Tobse]

Solange du von und nach JSON persistierst kannst du von den "intelligenten" Objekten nur profitieren. Die Argumente dei bei einem O/RM gegen eine sehr Komplexes Modell sprechen, treffen auf JSON (oder aug Graph-Datenbanken) nicht zu.

 

[JanHH]

Hm.. in der Tat gibt es (theoretisch, irgendwann mal) die Überlegung, das json-Modell doch in einzelne Entity-Objekte aufzubrechen und alles fein granuliert in die Datenbank zu tun - und zwar, um den z.Zt. stateful in einen stateless-Entwurf umzubauen, zwecks load balancing/clustering. Wäre damit ja viel einfacher. Aber ob es je dazu kommen wird.. eher fraglich. Momentan müsste bei einem stateless Entwurf bei jedem Seitenaufruf der gesamte json-String geladen und in Objekte konvertiert werden, was mir wie sehr sehr viel overhead und ressourcenfressend vorkommt. Aber dieser prozedurale Ansatz ist schon irgendwie eher doof.

 

[Tobse]

bei einem stateless Entwurf bei jedem Seitenaufruf der gesamte json-String geladen und in Objekte konvertiert werden, was mir wie sehr sehr viel overhead und ressourcenfressend vorkommt. Aber dieser prozedurale Ansatz ist schon irgendwie eher doof.

Zum einen: das muss nicht sein; im Java EE bereich können sich mehrere Requests den selben Heap und damit auch die selben Domain-Objekte teilen.
Zum anderen: wenn du mit einer Datenbank arbeitest, ist es ganz genau das selbe: Daten, die nicht da sind, müssen aus der DB geladen und in Objekte umgewandelt werden.

Dazu kommt: der Aufwand bei Verwendung einer Datenbank ist merkbar höher als beim JSON. Aber er ist so gerin, dass so ziemlich alle Web-Anwendungen (dieses Forum mit eingeschlossen) diesen "overhead" akzeptieren.
Durch optimierte Abfragen kann man da auch viel an Performance rausholen.

 

[JanHH]

Hm, stimmt. Ausserdem ist das besagte Datenmodell mehr so eine "Schablone", aber speichert keine session-spezifischen Daten (die landen dann in der Tat in entities in der Datenbank). man müsste das ganze Ding also nur einmal instanziieren, und alle requests könnten sich das teilen. hm.

 

[dayaftereh]

Wie sieht es mit einer NonSQL Datenbank aus, in der du deine Json-Objekt ablegen kannst und zusätzlich mit Hilfe der Datenbank suchen bzw filtern Kannst ?

 

[JanHH]

hm, das sagt mir erstmal gar nix, aber scheint mir nicht notwendig. das funktioniert alles gut so wies ist. das json objekt wird halt einfach als string gespeichert.