# Fragen zu: Servlets, Struts & Hibernate



## shoryuken (29. Nov 2006)

Hi folks!

nachdem ich jetzt diverse kleine Servlet-Applikationen mit Struts und Hibernate geschrieben habe steht nun ein etwas größeres Projekt an. Dazu habe ich noch einige Verständnis-Fragen und suche nach Best-Practices.

1. JSP/ActionServlet: Wie funktioniert das Zusammenspiel dieser beiden? Wie kommen die Informationen z.B. eines ActionForms in die JSP Seite ohne, dass das ActionServlet aufgerufen wird? Kommuniziert der TagHandler mit dem ActionServlet oder liest der Handler die struts-config neu ein?

2. Hibernate SessionFactory: Wo plaziert ihr diese? Im Servlet Context?

3. Hibernate: Ein Hibernate POJO ähnelt oft der zugehörigen Logik (bis auf die Methoden). Ist es eurer Meinung erlaubt und/oder tragbar Logik-Methoden in das POJO zu integrieren? (Nach dem MVC Prinzip)

Gruß,

shoryuken


----------



## SlaterB (29. Nov 2006)

1.
ein Aufruf an der Server wird in der struts-config irgendwo gemappt,
entweder auf eine Action oder eine JSP,
bevor dieser User-Code dran kommt, erledigt Struts seine Arbeit,
vor der Action wird das Form gefüllt,

ob vor der JSP auch weiß ich im Moment gar nicht, ich nehme es aber mal an, steht dann als Attribut im Request?
testen

was ist ein TagHandler?

---------

2.
eine andere Möglichkeit ist ein Singelton/ statische Variable

3.
nach dem MVC-Prinzip darf ins Model POJO keine Controller-Logik

wie man das nimmt, nun ja, 
also es gibt viele Logik die da nicht zu suchen hat,
andere macht dort oder zumindest nahe am POJO meiner Meinung nach schon Sinn, 
z.B. Ausgabeformatierungen oder das Laden zugehöriger Objekte,
wenn dies auch nur aus dem Aufruf anderer Operationen besteht,

schöner wirds vielleicht mit einem Hilfsobjekt, dass dem POJO zugeordnet ist bzw. andersrum


----------



## HLX (29. Nov 2006)

SlaterB hat gesagt.:
			
		

> ob vor der JSP auch weiß ich im Moment gar nicht, ich nehme es aber mal an, steht dann als Attribut im Request?



Die Instanz der ActionForm steht als Attribut im Request.


----------



## Guest (29. Nov 2006)

SlaterB hat gesagt.:
			
		

> 1.
> ob vor der JSP auch weiß ich im Moment gar nicht, ich nehme es aber mal an, steht dann als Attribut im Request?
> testen
> was ist ein TagHandler?



Mir ging es um den direkten Aufuf einer JSP Seite.  Mit TagHandler meinte ich die Klassen TagSupport und BodyTagSupport. Diese werden für die Struts-eigenen Taglibs benutzt. 
Mittlerweile habe ich aber heraus gefunden, dass die Klasse TagUtils Zugriffe auf ActionMappings, MessageResources etc erlaubt. Damit hat sich diese Frage geklärt 

zu 3. ein Beispiel: Login-Bereich 
Frage: Was kommt wohin nach dem MVC Prinzip?

1. Login/Password überprüfung: Wohin packe ich das HQL Statement und/oder die anschließende Passwort Überprüfung (Falls das nicht im Statement mit drin ist) 
Darf die Struts-Action Kontakt mit der Model Ebene haben oder muss/darf ich die Überprüfung und den Datenbank-Kontakt in der Logik kapseln.

2. Überprüfung der Session benötigt die HttpServletRequest Instanz. Das request selbst darf aber keinen Kontakt mit der Logik haben. Wohin also damit? 

3. Was würdet ihr in der Session speichern um den User wiederzuerkennen? Die Hibernate-POJO-Instanz (bzw. die ID) oder ein Bean was diese Instanz kapselt?

Wenn MVC dann auch richtig 

gruß


----------



## HLX (29. Nov 2006)

Anonymous hat gesagt.:
			
		

> 1. Login/Password überprüfung: Wohin packe ich das HQL Statement und/oder die anschließende Passwort Überprüfung (Falls das nicht im Statement mit drin ist)
> Darf die Struts-Action Kontakt mit der Model Ebene haben oder muss/darf ich die Überprüfung und den Datenbank-Kontakt in der Logik kapseln.
> 
> 2. Überprüfung der Session benötigt die HttpServletRequest Instanz. Das request selbst darf aber keinen Kontakt mit der Logik haben. Wohin also damit?


für beides gibt es die validate-Methode an der ActionForm. Diese ist zur Validierung zu überschreiben. Die Session kannst du auch an der Action überprüfen.



			
				Anonymous hat gesagt.:
			
		

> 3. Was würdet ihr in der Session speichern um den User wiederzuerkennen? Die Hibernate-POJO-Instanz (bzw. die ID) oder ein Bean was diese Instanz kapselt?



Ich würde die POJO-Instanz speichern, aber nur dann wenn ich die enthaltenen Informationen bei weiteren requests benötige.


----------



## SlaterB (29. Nov 2006)

ich rate jetzt auch nur mal:

1.)
die Action ruft eine Logikklasse mit Username/ Passwort auf 
checkLogin(user,pass);
und bekommt dann einen String oder ein User-Objekt zurück,
oder null wenn Passwort nicht erfolgreich

sie hat natürlich Kontakt zur Model-Ebene in dem Sinne, dass sie viele PoJOs hin-  und herreicht,
aber keinen direkten Kontakt zur DB-Ebene, wenn auch ein Befehl wie checkLogin praktisch einem "Select User" entspricht

2.)
macht die Action?!

3.)
ich bin für Username/ Id oder gleich POJO, warum nicht,
dafür ist es ja plain, damit es ganz losgelöst vor irgendwelchen Ladevorgängen überall und lange Zeit genutzt werden kann


----------



## shoryuken (29. Nov 2006)

HLX hat gesagt.:
			
		

> für beides gibt es die validate-Methode an der ActionForm. Diese ist zur Validierung zu überschreiben. Die Session kannst du auch an der Action überprüfen.



Die validate Methode der Action Form ist aber nur für eine syntaktische Validierung gedacht. Die semantische Überprüfung sollte eben nicht im Controller Bereich stattfinden (ob die ActionForm zum View oder Controller Bereich gehört darüber streiten ja die Geister. Ist hier ja auch nicht von Belang).

Bleibt immer noch die Frage ob die Model Ebene in den Logik Beans gekapselt werden sollte oder der Controller Bereich Zugriff auf die Model Ebene hat.



			
				SlaterB hat gesagt.:
			
		

> sie hat natürlich Kontakt zur Model-Ebene in dem Sinne, dass sie viele PoJOs hin- und herreicht,
> aber keinen direkten Kontakt zur DB-Ebene, wenn auch ein Befehl wie checkLogin praktisch einem "Select User" entspricht ?



Genau dieses hin und herreichen habe ich befürchtet .. Ich weiß nicht ob ich das so sinnvoll finde kommt aber auch auf das Problem drauf an.

gruß


----------



## HLX (29. Nov 2006)

shoryuken hat gesagt.:
			
		

> Die validate Methode der Action Form ist aber nur für eine syntaktische Validierung gedacht. Die semantische Überprüfung sollte eben nicht im Controller Bereich stattfinden (ob die ActionForm zum View oder Controller Bereich gehört darüber streiten ja die Geister. Ist hier ja auch nicht von Belang).



Um Himmels willen!  :shock: Weder Controller und schon garnicht View! Die ActionForm gehört definitiv ins Model! 

Zur Erläuterung - MVC in Struts:
View= AUSSCHLIESSLICH JSP
Model= ActionForm (Datenhaltung des Views) + Backend
Controller= Action: Verbindung zum Model (ActionForm + Backend) und Auswahl der View (--> findForward)

In der Validate-Methode sollten Dinge validiert werden, die möglichst vor Erreichen des Controllers abgefangen werden sollen.


----------



## shoryuken (29. Nov 2006)

HLX hat gesagt.:
			
		

> Um Himmels willen!  :shock: Weder Controller und schon garnicht View! Die ActionForm gehört definitiv ins Model!



Diese Diskussion wurde schon viel geführt. Ich sehe das anders:

Die ActionForm bietet nicht wesentlich mehr als einen vereinfachten Zugriff auf das request Objekt. Das ist sicherlich nicht wirklich View aber definitiv nicht Model, da:



			
				HLX hat gesagt.:
			
		

> Model= ActionForm (Datenhaltung des Views) + Backend
> 
> In der Validate-Methode sollten Dinge validiert werden, die möglichst vor Erreichen des Controllers abgefangen werden sollen.



der Kontakt zur View Ebene da ist - und das wäre nach dem MVC Prinzip unzulässig, wenn die ActionForm im Model-Bereich wäre. Ich würde die ActionForm neben den Actions im Controller Bereich ansiedeln.

gruß


----------



## HLX (30. Nov 2006)

:noe: 

Du sollstest dich auf jeden Fall nochmal mit dem MVC-Prinzip auseinandersetzen - und dich noch mehr über Struts informieren. Es gibt ziemlich eindeutige Indikatoren dafür, wo die ActionForm anzusiedeln ist:

*Die ActionForm hält die Daten der JSP-Datei. 
*View und Controller halten per Definition *NIEMALS* irgendwelche Ein-/Ausgabe-Daten. Damit gibt es keine Diskussion über die Einordnung der ActionForm.

Um den Zusammenhang Struts-MVC genauer zu erläutern: Hinter deiner Anwendung steckt ja nun ein bisschen mehr als nur die JSP und die beiden Klassen. Die einzelnen MVC-Bestandteile spiegeln sich also nicht nur darin, sondern auch im Struts-Framework wider.
Will heißen: der Controller besteht nicht nur aus deiner Action, sondern auch teilweise in den Verarbeitungsmechanismen von Struts. Es gibt tatsächlich keine direkte Kommunikation zwischen View und Model, da Bestandteile von Struts den Zugriff regeln. Durch Actions ist es dir freigestellt, den Controller zu erweitern. Dies ist in JSF z.B. nicht vorgesehen. Hier gibt es ein FacesServlet. Controller-Aktivitäten sind hier durch die Config-Datei festzulegen. Es gibt keinen zusätzlichen Code. In Struts ist das anders. Aber auch hier sind große Teile der MVC-Kommunikation im verborgenen. Genau gesehen wird also in der Validate-Methode alles abgearbeitet, was vor DEINEN Controller-Aktivitäten geschehen soll. Tatsächlich war hier der Controller schon aktiv.

Der Controller beschäftigt sich nur mit der Anwendungssteuerung. Er kommuniziert mit Model und View. Er bekommt aus Validierung und Backend-Operationen ein Ergebnis und entscheidet daraufhin über die Ausgabe (View).

Ich hoffe, das ich damit einige Zusammenhänge zwischen MVC und Struts etwas besser verdeutlichen konnte.


----------

