Liste over stater

Og nå begynner moroa. Vi vil studere tilstandene til Entitetsobjekter. Du må betale for alt, og for å bruke Hibernate også. Synes du ikke det er en slik pris å lære HQL? Nei, livet er litt mer komplisert.

Hvis du har et slags Entity-objekt som du kan lagre i databasen ved hjelp av Hibernate, kan dette objektet fra Hibernate-synspunktet ha fire tilstander:

  • Flyktig
  • Vedvarende (eller administrert)
  • Frakoblet
  • Fjernet

Og for å interessere deg, vil jeg legge til dette bildet til denne forelesningen:

Flyktig

Faktisk er alt mye enklere enn det ser ut til, men ikke uten nyanser. For eksempel har hvert Entity-objekt som du eksplisitt opprettet ved hjelp av Java-kode, og ikke lastet inn fra databasen med Hibernate, en Transient (gjennomsiktig) status.

EmployeeEntity employee = new EmployeeEntity();

Forbigående-statusen betyr at Hibernate ikke har noen anelse om dette objektet, og ingen handling på objektet påvirker Hibernate, og heller ikke Hibernates arbeid med dette objektet.

Java webinar

Slike objekter kalles også POJO - Plain Old Java Object . Begrepet brukes ofte som det motsatte av ulike objekter med vanskelig oppførsel. Husker du Moc-objektene som Mockito laget? Her er de ikke POJO.

Hvis en klientkode fungerer med et objekt med Transient-status, kan interaksjonen deres beskrives med et superenkelt skjema:

Vedvarende eller administrert

Det nest vanligste tilfellet er objekter relatert til Hibernate-motoren. Statusen deres kalles vedvarende (eller administrert). Det er nøyaktig to måter å få et objekt med denne statusen på:

  • Last inn objekt fra Hibernate.
  • Lagre objekt i dvalemodus.

Eksempler:

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

Et slikt objekt tilsvarer vanligvis en slags post i databasen, det har en ID og lignende. Dette objektet er knyttet til Hibernate-økten, og kan generelt ikke representeres av et reelt objekt, men av en slags proxy.

Det er ganske mulig at etter å ha kalt session.load()- metoden vil du få tilbake et eller annet stub-objekt (proxy), og alle kall til databasen vil bare bli utført etter å ha kalt metodene til dette objektet. Men vi vil snakke om slike detaljer litt senere.

Og interaksjonen mellom klientkoden og objektet i administrert status kan beskrives med følgende bilde:

Frakoblet

Den neste tilstanden er når objektet har blitt løsrevet fra økten. Det vil si at når objektet ble knyttet til Hibernate-økten, men så ble økten lukket eller transaksjonen avsluttet, og Hibernate overvåker ikke lenger dette objektet.

Eksempel:

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

I det første eksemplet ble økten stengt. I det andre tilfellet har vi eksplisitt indikert at vi ønsker å koble objektet fra sesjonen ved å bruke evict()- metoden .

Den nye kode-objekt-interaksjonsordningen vil se slik ut:

Og det er her det blir interessant. Hvis objektet ditt ble hentet fra Hibernate, er det sannsynlig at du fikk en proxy i stedet for et ekte objekt. Og dette proxy-objektet, etter å ha koblet fra sesjonen, vil gi unntak når metodene kalles.

Dette er det vanligste problemet for alle nybegynnere når de jobber med Hibernate. Du må vite nøyaktig til enhver tid svaret på spørsmål som dette når du arbeider med et Entity-objekt :

  • Har du et ekte objekt eller bare en proxy fra et ekte objekt?
  • Er du i en transaksjon eller ikke?
  • Er det en lese-skrive-transaksjon eller en skrivebeskyttet transaksjon?
  • Håndteres objektet av LazyLoading-mekanismen?
  • Hvilke deler av objektet er allerede lastet inn i minnet, og hvilke deler vil bli lastet når det åpnes?
  • Hvordan er objektet ditt koblet til avhengige objekter?

Den gode nyheten er at det meste av tiden er åpenbart. Men du må fortsatt forstå hvordan det hele fungerer under panseret. Deklarativ programmering er hva det er - du kan skrive kode på 10 minutter, forstå hvorfor det ikke fungerer som det skal - på 10 timer :)

Fjernet

Og den siste tilstanden Entity-objektet ditt kan ha er Removed. Som du sikkert allerede har gjettet ut fra navnet, er dette tilstanden til et eksternt objekt.

Denne tilstanden vises på grunn av det faktum at hvis du sletter et objekt fra databasen, vil ikke Java-objektet umiddelbart forsvinne hvor som helst.

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