Architektur- Frage

[Generic1]

Hallo,

ich hätte eine Frage zur Struktur meiner Spring 2.5 Enterprise Applikation.
Ich verwende für das Frontend String MVC -> der Controller holt also die Daten aus der Domain.
Meine Frage wäre jetzt, wie ich vom Controller aus die Daten aus der Domain hole.

Momentan schauts so aus, dass ich:

  1. vom Controller aus auf eine Klasse XXXRepository zugreife und über dieses Repository die Daten 
      für die Form (ComboBoxen - z.B.: Titel- ComboBox (Dr., Mag, DI, ...)) hole und setzt diese Daten 
      dann in die Form in der View (bzw. das geht eh über das Model automatisch), also
      [B] View <-> Model <-> Controller <-> Repository <-> Hibernate <-> Datenbank[/B]
 
  2. vom Controller aus speichere ich nach dem Drücken des Submit- Button in der View die Daten der 
      Form in verschiedene Datenbank- Tabellen, hierfür hab ich mir einen XXXService gemacht, da das 
      speichern in mehreren Schritten erfolgt (schaun ob die Daten in der DB schon gibt, wenn nicht -> 
      speichern usw.). Der Service greift übrigens über das Repository auf die DB zu, also:
      [B] View <-> Model <-> Controller <-> Service <-> Repository <-> Hibernate <-> Datenbank[/B]

Meine Frage wäre jetzt, soll ich Punkt eins auch über den Service machen oder kann man das so lassen. Mir würde es aus Architektonischer Sicht besser vorkommen, wenn alles über den Service laufen würde, auf der anderen Seite sollte ein Service so einfach wie möglich sein, stateless sein und nicht viel logik beinhalten.

Was sagt ihr dazu, wie würdet Ihr es machen um ein gutes Design zu haben?
Vielen Dank,
lg
Generic1

 

[Generic1]

Kann da jemand was dazu schreiben oder fehlen noch informationen?
lg

 

[daNny]

Ich bin nicht der Auffassung, dass gerade ein Service wenig Logik beinhalten soll.
Im Gegenteil: Für mich ist das gerade DER Teil, in dem die wichtige Logik stehen sollte.

Ich handle das immer so, dass mein Controller stets auf den Service zugreift, und nicht auf das Repository/DAO direkt. Im Service habe ich z.B. auch die Transaktionssteuerung, da ein Service ja auch ggf. auf mehrere Repos/Daos zugreift.

 

[Gast2]

Würde ich auch so machen dass der Service immer auf die DAO Schicht zugreift. Und nicht der Controller direkt.

Außerdem würde ich die BU Logik auch in den Service verlagern.

 

[maki]

Meine Frage wäre jetzt, soll ich Punkt eins auch über den Service machen oder kann man das so lassen. Mir würde es aus Architektonischer Sicht besser vorkommen, wenn alles über den Service laufen würde,

Dann mache es doch so

auf der anderen Seite sollte ein Service so einfach wie möglich sein, stateless sein und nicht viel logik beinhalten.

Das ist so allgemein nicht richtig, da verwechselst du ein paar Dinge.
Stateless bevorzugt: Bei "Standard" EJB Projekten empfiehlt man das
Einfach und keine Logik: das bezieht sich speziell auf DDD, gilt diort aber nur für die sog. "ApplicationServices"

 

[FArt]

Stateless bevorzugt: Bei "Standard" EJB Projekten empfiehlt man das

Nicht nur, aber auch. Im Prinzip wird die Architektur dadurch (zumindest an dieser Stelle) leichtgewichtiger. Bereiche, die keinen Status halten sind im Zweifelsfall sehr einfach zu skalieren.