nicht angemeldet
hi pgoetz,
vielen dank für die Antwort. Hast alles schön detailiert erklärt.
Arbeitest Du hier ausschließlich mit JSPs? Wenn ja, dann solltest Du Dich vor der Verwendung von Hibernate erst noch kurz in Model2 bzw. MVC für Java Webanwendungen einlesen und Deine Anwendung entsprechend umstellen. Kurz gesagt geht es dabei darum, dass eine JSP ausschließlich die View einer Anwendung ist, für die Clientlogik wird ein Servlet verwendet. Das Servlet sollte dann nicht direkt mit Hibernate arbeiten, sondern den Zugriff auf die Geschäftslogik über eine Serviceklasse abkapseln. Das ist auch wichtig für die Transaktionssteuerung und die korrekte Einhaltung von Transaktionsgrenzen (s.u.).
ja, ich hatte schon mal gelesen, dass man Ausgabe für Browser, Logik usw. trennen sollte. Bisher habe ich viel in JSP's geregelt gehabt und paar Sachen in servlets ausgelagert. Ging auch ganz schön, wenn ich von JSP aus Daten dann in sevlet weitergeleitet/übergeben hatte und dann wieder zurück. Die JSP selbet hatte manchmal auch selber Java-code gehabt. Zum Beispiel Usereingaben prüfen oder je nach Parameter im Request oder Eingabe dann ein ein anderes Design/Html-Code Ausgabe usw.
Trennung zwischen Design-Ausgabe und Logik usw. wäre natürlich gut. Ich frag mich aber, ob man das überhaupt schön trennen kann, da man manchmal je nach Request verschiedene HTML-Codes auch hat, oder Text. Innerhalb von Texten hat man manchmal Formatierungen usw.
Aber, ich schau mir mal das MVC mal an, vielleicht finde ich ja gute Musterbeispiele.
Wenn Du jetzt aber mit Deinem Objekt die Hibernate Session verlässt (weil Du das Objekt aus dem Service an das Servlet übergibst), dann ist das Objekt "detached" und wird verwendet wir ein normales POJO sonst auch. Wenn es jetzt aber vom Benutzer geändert wird (über ein Formular, Du lädst das Objekt aus der Session, gibst ihm neue Eigenschaften und sendest es an den Service), dann muss es erst "reattached" werden, damit Hibernate wieder eine Verbindung vom Objekt zur Datenbank hat und die Attribute entsprechend aktualisieren kann (in der DB).
ach so. ok, ich lese mich mal in Hibernate ein. Dann ist da wohl vorsicht geboten, wenn ich mit Hibernate von der DB ein Objekt mappe und mit dem gemappten Objekt weiterarbeite. (Um die Hibernate-Session nicht zu verlassen, sollte ich dann das Objekt nicht an das Servlet übergeben.... Das gemappte Ergebnis kommt doch aber wahrscheinlich in das Servlet rein? Wie gesagt, bevor ich dumme Fragen stelle, lese ich miche rst einmal ein :-) )
Das ist eigentlich die einfachste Frage an Deinem Vorgehen. ;)
Damit ein Objekt über Systemgrenzen hinweg verschickt werden kann, muss es serialisierbar sein (also in einen Bytestrom reversibel transferierbar). Das passiert in Java über das Marker-Interface java.io.Serializable. Wenn eine Klasse dieses Interface implementiert, dann wird damit versichert, dass alle Attribute serialisiert werden können (also primitive Datentypen sind oder selbst serialisierbare Objekte). Das sollte bei Hibernate POJOs immer der Fall sein, weil die ja gerne mal über verschiedene Maschinen hinweg transportiert werden.
Optimal. Ich schau mir Intefaces dann auch nochmal an. (Wenn man ein Interface addiert, war es ja so ähnlich wie eine Vererbung. Mit abstract wird man ja gezwungen manche Methode zu implemetieren und manchmal kann man auch Methoden erben oder auch Objektvariablen nutzen. Hoffentlich habe ich das noch richtig in Erinnerung
Noch ein Hinweis, weil das früher oder später wichtig für Dich wird: Lese Dich (sofern noch nicht passiert) in die Bedeutung der Methoden equals und hashCode ein. Diese sind zwar nicht nur für Hibernate wesentlich, aber viele Java-Entwickler können trotzdem nicht damit umgehen. Es gibt auch in der Hibernate Doku ein spannendes Kapitel dazu.
hashCode sagt mir jetzt nichts. Mit equals schaut man ja, ob die Referenz/Zeiger des Objekts gleich ist.
Grüße