Guten Morgen!
[...]
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.
Ja, das geht schon gut. Trennung von Logik und Repräsentation heißt ja nicht, dass man in einer JSP nicht anhand eines Zustands entweder die eine, oder eine andere Meldung ausgeben darf (z.B. Erfolgs- und Fehlermeldung). Die Grenze sind bei mir Scriptlets. In meinen Projekten dulde ich keine Scriptbereiche in JSPs. Wenn es Logik gibt, die innerhalb der View verwendet werden muss (z.B. zusammensetzen eines Links), dann wird das in ein Tag ausgelagert. Ansonsten reicht die JSTL mit den Standardtags (z.B. c:if, c:forEach, fmt:formatDate, ...). Ich arbeite jetzt seit einigen Jahren fast ausschließlich in Java Webprojekten und habe noch in keinem Projekt ein Scriptlet benötigt. Und alle Daten, die in der View benötigt werden, können im Servlet ermittelt und passend aufbereitet werden.
[...]
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 :-) )
Man kann das Objekt schon an das Servlet übergeben, aber es sollte vorher detached werden, also von der Hibernate Session abgekoppelt. Hier sollte man alle Daten mitnehmen, die man in der View benötigt (Stichwort lazy loading), da man ansonsten im Client beim Zugriff auf untergeordnete Objekte im Objektgraphen eine LazyLoadingException einfängt. Aber das ist dann schon die fortgeschrittenere Thematik.
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
Ja, fast. Abstrakte Klassen werden nicht gezwungen, Methoden zu implementieren. Nicht-abstrakte Klassen müssen alle Methoden ihrer Interfaces implementieren. Abstrakte Klassen dürfen Methoden implementieren, können aber bestimmte Methoden abstrakt (nicht implementiert) weitervererben. Beim Interface Serializable ist das allerdings kein Problem, weil es ein reines Marker-Interface ist und keine Methoden definiert, die implementiert werden müssten. Es zeigt nur an, dass das Objekt serialisierbar ist.
[...]
hashCode sagt mir jetzt nichts. Mit equals schaut man ja, ob die Referenz/Zeiger des Objekts gleich ist.
equals existiert ohne hashCode nicht. Die beiden Methoden hängen eng zusammen, deshalb solltest Du Dich mit denen ruhig ein wenig intensiver beschäftigen. Wenn man sich nur um eine Methode kümmert oder nicht um beide gleichzeitig, können die ekelhaftesten Fehler entstehen, die man ewig sucht.
Schöne Grüße,
Peter