nicht angemeldet
Hallo,
Seriazible sagt dann einfach kurz, dass ich den Zustand den Objekts (egal in was für einer Form auch immer) irgendwo speichern und später wieder auslesen/erstellen kann. Passt meine Aussage?
Ja, das triffts. Wobei Du natürlich die Objekte nicht zwingend speichern musst - Serialisierung kommt z.b. auch beim Übertragen von Objekten zum Tragen (Du könntest z.b. ein serialisiertes Java-Objekt per HTTP oder welchem Protokoll auch immer an einen anderen Host schicken, der es dann wieder auspacken und benutzen kann).
(Wie etwas genau zu serialisieren ist, legt dann der oder die Schnittstelle fest, die mit dem Objekt arbeitet?)
Genau. Standardmässig kann erstmal jedes Objekt serialisiert werden, sobald es das Serializable Interface implementiert (nicht immer ergibt das Sinn, vgl. Datenbankverbindung, aber prinzipiell geht es).
Nur wenn Du die Standard-Serialisierung von Java aus irgend einem Grund anders haben willst, kannst Du in Deiner Klasse die Methoden "readObject" und "writeObject" überladen, und damit das Serialisieren so machen, wie Du es willst.
Bei meinem Programm hat mir nur das nicht gefallen, dass pro Klick/Aktion eines Nutzers manchmal mehrere Querys abgesetzt wurden. Da muss ich mir etwas einfallen lassen, dass es sehr wenig Querys bleiben. Ist halt schwierig, wenn man allgemeine Querys hat, die man für die Ansicht benötigt und dann gleichzeitig noch speziell Daten eines eingeloggten Nutzers)
Ich glaube, das Problem auf dass Du da stösst, ist ein "Klassiker":
Der Object-relational impedance mismatch.
Vielleicht schonmal gehört? (Vielleicht geh ich jetzt zu sehr in die Tiefe, also lies einfach drüber weg, wenns Dich nicht interessiert ;) ):
Das Problem ist, dass sich Objektorientierung und relationale Datenbanken eigentlich nicht wirklich gut vertragen:
Nehmen wir an, Du hast eine Tabelle LOGGED_USERS, die alle eingeloggten User speichert und eine Tabelle USER_DETAILS, die zu jedem Benutzer die Details beinhaltet. Du hast eine Methode "getLoggedInUsers" die die LOGGED_USERS-Tabelle ausliest und daraus eine Liste aus "User"-Objekten erzeugt, und eine Methode "fetchUserDetails()", welche das User-Objekt mit den User-Details befüllt.
Jetzt möchtest Du (schön objektorientiert) eine Liste aller eingeloggten User mit ein paar Daten aus der Details-Tabelle (vielleicht Vor- und Nachname) anzeigen:
Iterator<User> users = UserListController.getLoggedInUsers().iterator();
while (users.hasNext()) {
User user = users.next();
user.fetchUserDetails();
System.out.println(user.getVorname()+" "+user.getNachname());
}
Ja doof. Jetzt wird in der Schleife für JEDEN Benutzer ein DB-Request gemacht.
Also die User-Details-Tabelle vielleicht lieber in der getLoggedInUsers()-Methode auslesen, in dem man sie mit der LOGGED_USERS-tabelle joint (und sich dann die fetchUserDetails-Methode sparen)?
Könnte man machen, aber was, wenn man dann die Details gar nicht braucht, dann hätte man umsonst Performance für einen JOIN verbraten....
=> Wie mans macht ists Mist. "Object Relational Impedance mismatch" eben :)
Große Systeme benutzen deswegen Objekt-relationale-Mapper, welche sich darum kümmern, DB-Objekte möglichst performant und geschickt aus der Datenbank zu holen und sie zu cachen, damit die Datenbank-Aufrufe auf ein Minimum beschränkt bleiben.
Für Java erledigt das z.b. Hibernate.
Viele Grüße,
Jörg