Liste over stater

Og nu begynder det sjove. Vi vil studere tilstanden af ​​Entitetsobjekter. Du skal betale for alt, og også for at bruge Hibernate. Synes du ikke, at det er sådan en pris at lære HQL? Nej, livet er lidt mere kompliceret.

Hvis du har en form for Entity-objekt, som du kan gemme i databasen ved hjælp af Hibernate, kan dette objekt fra Hibernate-synspunktet have fire tilstande:

  • Forbigående
  • Vedvarende (eller administreret)
  • Fritliggende
  • Fjernet

Og for at interessere dig, vil jeg tilføje dette billede til dette foredrag:

Forbigående

Faktisk er alt meget enklere, end det ser ud til, selvom det ikke er uden nuancer. For eksempel har hvert Entity-objekt, som du eksplicit oprettede ved hjælp af Java-kode og ikke indlæste fra databasen ved hjælp af Hibernate, en Transient (gennemsigtig) status.

EmployeeEntity employee = new EmployeeEntity();

Forbigående status betyder, at Hibernate ikke har nogen idé om dette objekt, og ingen handling på objektet påvirker Hibernate, og Hibernates arbejde med dette objekt har heller ikke.

Java webinar

Sådanne objekter kaldes også POJO-Plain Old Java Object . Udtrykket bruges ofte som det modsatte af forskellige objekter med vanskelig adfærd. Kan du huske de Moc-objekter, som Mockito skabte? Her er de ikke POJO.

Hvis en klientkode fungerer med et objekt med Transient-status, kan deres interaktion beskrives ved et supersimpelt skema:

Vedvarende eller administreret

Det næstmest almindelige tilfælde er objekter relateret til Hibernate-motoren. Deres status kaldes vedvarende (eller administreret). Der er præcis to måder at få et objekt med denne status på:

  • Indlæs objekt fra Hibernate.
  • Gem objekt i Hibernate.

Eksempler:

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

Sådan et objekt svarer normalt til en form for post i databasen, det har et ID og lignende. Dette objekt er knyttet til Hibernate-sessionen og kan generelt ikke repræsenteres af et rigtigt objekt, men af ​​en slags proxy.

Det er meget muligt, at efter at have kaldt session.load()- metoden , vil du få et eller andet stub-objekt (proxy) tilbage, og alle kald til databasen vil kun blive udført efter at have kaldt dette objekts metoder. Men vi vil tale om sådanne detaljer lidt senere.

Og interaktionen mellem klientkoden og objektet i Administreret status kan beskrives med følgende billede:

Fritliggende

Den næste tilstand er, når objektet er blevet løsrevet fra sessionen. Det vil sige, når objektet blev knyttet til Hibernate-sessionen, men derefter blev sessionen lukket, eller transaktionen sluttede, og Hibernate overvåger ikke længere dette objekt.

Eksempel:

session.close();
session.evict(entity);

I det første eksempel var sessionen lukket. I det andet tilfælde har vi eksplicit angivet, at vi ønsker at adskille objektet fra sessionen ved hjælp af evict()- metoden .

Det nye kode-objekt interaktionsskema vil se sådan ud:

Og det er her, det bliver interessant. Hvis dit objekt blev hentet fra Hibernate, så er det sandsynligt, at du fik en proxy i stedet for et rigtigt objekt. Og dette proxyobjekt vil, efter at have afbrudt forbindelsen fra sessionen, give undtagelser, når dets metoder kaldes.

Dette er det mest almindelige problem for alle begyndere, når de arbejder med Hibernate. Du skal kende præcist på et givet tidspunkt svaret på spørgsmål som dette, når du arbejder med et Entity-objekt :

  • Har du et rigtigt objekt eller bare en proxy fra et rigtigt objekt?
  • Er du i øjeblikket i en transaktion eller ej?
  • Er det en læse-skrive-transaktion eller en skrivebeskyttet transaktion?
  • Styres objektet af LazyLoading-mekanismen?
  • Hvilke dele af objektet er allerede indlæst i hukommelsen, og hvilke dele vil blive indlæst, når de tilgås?
  • Hvordan er dit objekt forbundet med afhængige objekter?

Den gode nyhed er, at det meste af tiden er indlysende. Men du skal stadig forstå, hvordan det hele fungerer under motorhjelmen. Deklarativ programmering er hvad det er - du kan skrive kode på 10 minutter, forstå hvorfor det ikke virker som det skal - på 10 timer :)

Fjernet

Og den sidste tilstand, dit Entity-objekt kan have, er Removed. Som du sikkert allerede har gættet ud fra navnet, er dette tilstanden for et fjerntliggende objekt.

Denne tilstand vises på grund af det faktum, at hvis du sletter et objekt fra databasen, vil Java-objektet ikke umiddelbart forsvinde nogen steder.

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