Struts / Hibernate Pattern

[e.motion]

Hallo,
ich bin gerade dabei eine Webanwendung zu schreiben.

Als MVC-Framework benutze ich Struts.
Als O/R Mapper benutze ich Hibernate.

Nun müssen meine Views (Tiles + JSP) auch Daten aus der Datenbank anzeigen.

Ich könnte ein benutzerdefiniertes "Hibernate" Tag schreiben, welches dann direkt von den JSP Files aus die Daten aus der Datenbank liest.

Jedoch habe ich gelesen, dass dies sei eine Verletzung des MVC-Pattern ist.

Eine 2. Lösung wäre, dass ich vor jedes JSP File nochmal ein Servlet bzw. Action schalte, welches dann die Daten aus der Datenbank list und sie per Request an JSP Files weitergibt.

Statt vor jeden View eine Action zu schalten könnte ich ja auch einfach für jeden View einen eigenen Filter schreiben der dann die Daten aus der Datenbank liest und diese über das Request-Objekt weitergibt.

Gibt es ein anderes, besseres Entwurfsmuster?
Oder wenn nicht welche von diesen ist wohl am besten geeignet?

MfG e.motion

 

[Thomas Darimont]

Hallo!

Ich denke du solltest auf Variante 2 gehen und eben vor bzw. hinter jede View eine Action legen, welche die ActionForms die der View als "Datencontainer" dienen "zu bevölkern".
Dazu können die Actions dann Hibernate bemühen um die für die ActionForms benötigten Daten einzusammeln.

Gruß Tom

 

[e.motion]

Vielen Dank.

Aber sollte man die Daten nicht einfach in normalen Beans übergeben?
Sind ActionForms nicht nur für Formulare gedacht?

 

[Thomas Darimont]

Hallo!

Eigentlich schon, wenn du Listen anzeigen willst wäre es natürlich besser irgendwo eine Collection mit deinen gewünschten Anzeigeelemente zu füllen und diese dann über die Action in den request Bereich der JSP zu geben so das man dort ganz bequem z.Bsp. mittels JSTL tags darauf zugreifen und drüber interieren kann.

Gruß Tom

 

[CHaoSlayeR]

Hi,

ich möchte hier auch mal meine Erfahrung preisgeben... ;-)

ich selbst arbeite seit einiger Zeit an einem Projekt, welches Struts und Hibernate nutzt. Innerhalb dieses Projekts gibt es viele Actions, die teilweise auf verschiedene jsp's verweisen und an sie request-Attribute bzw. Beans übergeben (mittels mapping.findForward("strutsForward") kann man verschiedene Seiten anzeigen, über die gleiche Action). Hibernate läuft bei diesem Projekt weder in den Actions noch im View! In die Actions sollte so wenig wie möglich Logik hinein, daher sind bei diesem Projekt in den Actions nur Aufrufe zum holen oder setzen von Attributen/Parametern zu finden. Die eigentliche Arbeit finden auf Controller-Ebene in Helper-Klassen statt, die dann auf das Modell zurückgreifen und die eigentlichen Daten dann per Hibernate persistieren bzw. laden.

Übergeben werden nur Beans, bzw. Formular-Inhalte und nur selten mal eine Liste oder ein Set per request-Attribut an die jsp's. Die jsp's selbst enthalten dann auch keinerlei Logik, sodass die Entwicklung einer größeren Web-Applikation erheblich erleichtert wird, weil alle beteiligten Entwickler (und ich selbst vor allem!) genau weiß, wo was zu finden ist. Eine gute Struktur ist das A und O! Dafür sollte man genügend Zeit zu Anfang investieren und sie dann konsequent (! mein Schwachpunkt manchmal) umsetzen...

Resumeé:
- kein Hibernate in jsp's!
- kein Hibernate in Action's!
- stattdessen lieber eine Helper-Klasse schreiben, die die Hibernate-Arbeit übernimmt

ich hoffe ich konnte helfen...

MfG, C]-[aoSlayeR

 

[Aufziehvogel]

Re: Struts / Hibernate Pattern (OT)

vielleicht ein wenig OffTopic, passt aber generell zu der Thematik die hier besprochen wird

TSS Link: http://www.theserverside.com/news/thread.tss?thread_id=31742

 

[Thomas Darimont]

Hallo!

Ob man Hibernate Konstrukte innerhlab von Actions verwenden will oder nicht hängt IMHO davon ab wie sehr man ins Detail gehen will. Sprich in "kleineren" Struts-Anwendungen welche beispielsweise nur "stumpfe" Dateneingabe/ Ausgabe Formulare mit wenig Geschäftslogik beinhalten kann man ruhig Hibernate Konstrukte innerhalb von Actions ohne die Verwendung einer eigenen Zwischenschicht für die Geschäftslogik benutzen. Bei Anwendungen mit komplexer Geschäftslogik kann es schon sinnvoll sein dafür eine eingene Schicht zu bilden und die Persitenzlogik dorthin zu verschieben.

Gruß Tom

 

[e.motion]

Hallo,
hab mich inzwischen auch schon für Helper-Klassen entschieden.

Die Helper Klassen sind doch die so geannnten Data Access Objects oder?

Gruß

 

[Thomas Darimont]

Hallo!

DAO's sollten ausser vielleicht speziellen finder-Methoden IMHO keine Geschäftslogik enthalten insofern würde ich DAO's nur dem Data Access Layer zuordnen der letztendlich vom BusinessLayer verwendet wird. DAO's sind "blöd" und haben in der Regel keine Ahnung von der Geschäftslogik.

Gruß Tom