Levenscyclus van Hibernate Entity-objecten

Lijst van staten

En nu begint het plezier. We zullen de toestanden van entiteitsobjecten bestuderen. Je moet voor alles betalen, ook voor het gebruik van Hibernate. Denk je niet dat het leren van HQL zo'n prijs is? Nee, het leven is een beetje ingewikkelder.

Als u een soort Entity-object hebt dat u met Hibernate in de database kunt opslaan, dan kan dit object vanuit het oogpunt van Hibernate vier statussen hebben:

• Vergankelijk
• Aanhoudend (of beheerd)
• Losgemaakt
• VERWIJDERD

En om je te interesseren, voeg ik deze foto toe aan deze lezing:

Vergankelijk

In feite is alles veel eenvoudiger dan het lijkt, hoewel niet zonder nuances. Elk Entity-object dat u expliciet met Java-code hebt gemaakt en niet met Hibernate uit de database heeft geladen, heeft bijvoorbeeld een tijdelijke (transparante) status.

EmployeeEntity employee = new EmployeeEntity();

De tijdelijke status betekent dat Hibernate geen idee heeft van dit object en dat geen enkele actie op het object van invloed is op Hibernate, noch op het werk van Hibernate aan dit object.

Dergelijke objecten worden ook wel POJO-Plain Old Java Object genoemd . De term wordt vaak gebruikt als het tegenovergestelde van verschillende objecten met lastig gedrag. Herinner je je de Moc-objecten die Mockito heeft gemaakt? Hier zijn ze geen POJO.

Als sommige clientcode werkt met een object met de status Transient, kan hun interactie worden beschreven door een supereenvoudig schema:

Aanhoudend of beheerd

Het volgende meest voorkomende geval zijn objecten die verband houden met de Hibernate-engine. Hun status wordt Persistent (of Beheerd) genoemd. Er zijn precies twee manieren om een ​​object met deze status te krijgen:

• Object laden vanuit Hibernate.
• Object opslaan in slaapstand.

Voorbeelden:

Employee employee = session.load(Employee.class, 1);

Employee employee = new Employee ();
session.save(employee);

Zo'n object komt meestal overeen met een soort record in de database, heeft een ID en dergelijke. Dit object is gekoppeld aan de Hibernate-sessie en kan over het algemeen niet worden weergegeven door een echt object, maar door een soort proxy.

Het is heel goed mogelijk dat u na het aanroepen van de methode session.load() een stub-object (proxy) terugkrijgt en dat alle aanroepen naar de database pas worden uitgevoerd nadat de methoden van dit object zijn aangeroepen. Maar we zullen later over dergelijke details praten.

En de interactie tussen de klantcode en het object in de status Beheerd kan worden beschreven met de volgende afbeelding:

Losgemaakt

De volgende status is wanneer het object is losgekoppeld van de sessie. Dat wil zeggen, zodra het object was gekoppeld aan de Hibernate-sessie, maar de sessie werd afgesloten of de transactie werd beëindigd, en Hibernate bewaakt dit object niet langer.

Voorbeeld:

session.close();

session.evict(entity);

In het eerste voorbeeld was de sessie gesloten. In het tweede geval hebben we expliciet aangegeven dat we het object willen loskoppelen van de sessie met behulp van de methode evict() .

Het nieuwe code-object-interactieschema ziet er als volgt uit:

En hier wordt het interessant. Als uw object is verkregen van Hibernate, heeft u waarschijnlijk een proxy gekregen in plaats van een echt object. En dit proxy-object zal, nadat het de verbinding met de sessie heeft verbroken, uitzonderingen genereren wanneer zijn methoden worden aangeroepen.

Dit is het meest voorkomende probleem voor alle beginners bij het werken met Hibernate. U moet op elk moment exact het antwoord weten op vragen als deze wanneer u met een Entity-object werkt :

• Heb je een echt object of alleen een proxy van een echt object?
• Zit je momenteel in een transactie of niet?
• Is het een lees-schrijftransactie of een alleen-lezen transactie?
• Wordt het object beheerd door het LazyLoading-mechanisme?
• Welke delen van het object zijn al in het geheugen geladen en welke delen worden geladen wanneer ze worden geopend?
• Hoe is uw object verbonden met afhankelijke objecten?

Het goede nieuws is dat het meestal duidelijk is. Maar je moet nog steeds begrijpen hoe het allemaal werkt onder de motorkap. Declaratief programmeren is wat het is - je kunt code schrijven in 10 minuten, begrijpen waarom het niet werkt zoals het zou moeten - in 10 uur :)

VERWIJDERD

En de laatste status die uw Entity-object kan hebben, is Verwijderd. Zoals je waarschijnlijk al geraden hebt uit de naam, is dit de status van een object op afstand.

Deze status verschijnt omdat als u een object uit de database verwijdert, het Java-object niet meteen overal verdwijnt.

Employee employee = session.load(Employee.class, 1);
//after loading the object's state is Persisted

session.remove(employee);
//after deletion, the state of the object is Removed

session.save(employee);
//and now Persisted again

session.close();
//and now the Detached state