Fragen zu: Servlets, Struts & Hibernate

[shoryuken]

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]

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]

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]

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]

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.

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]

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]

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.

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]

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]

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:

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]

: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.