java - number - sql type jdbc type




Utilizzo di wrapper Classe intera o primitiva int in modalità hibernate (2)

Nella società in cui lavoro, abbiamo questa importante discussione sull'opportunità di utilizzare le classi wrapping per le primitive (java.lang.Integer, java.lang.Long) o se utilizzare i tipi primitivi direttamente nei POJO che mappano Entità alle tabelle in ibernazione.

L'idea è che vogliamo che questi valori non siano nulli nel database.

Gli argomenti a favore dell'uso delle primitive:

  • Gestire questi valori come int significa che non possono mai essere nulli, in questo modo rendendo impossibile ottenere inavvertitamente un riferimento null sul campo.
  • int = 32/64 bit di memoria. Numero intero = 16 byte di memoria ed è anche più lento

Gli argomenti a favore dell'utilizzo degli oggetti wrapper:

  • Possiamo aggiungere un vincolo a livello di database per impedire sempre di ottenere valori nulli
  • Possiamo finire con dati fuorvianti, possiamo avere zero invece di null nel database ogni volta che l'utente non imposta un valore e i dati bacati sono un problema difficile.
  • Gli oggetti hanno un potere più espressivo dei primitivi. Abbiamo valori nulli e anche valori interi, quindi possiamo convalidarli più facilmente utilizzando le annotazioni per esempio (javax.validation.constraints.NotNull).

Ho pensato che dovrebbe essere menzionato:

La raccomandazione di ibernazione (sezione 4.1.2) che utilizza proprietà non primitive nelle classi persistenti fa effettivamente riferimento - come titolato - alle proprietà dell'identificatore :

4.1.2. Fornire una proprietà identificatore

Cat ha una proprietà chiamata id. Questa proprietà si associa alle colonne chiave principali di una tabella di database. La proprietà potrebbe essere stata chiamata nulla, e il suo tipo potrebbe essere stato qualsiasi tipo primitivo, qualsiasi tipo di "wrapper" primitivo, java.lang.String o java.util.Date.

...

Si consiglia di dichiarare le proprietà dell'identificatore con nome coerente nelle classi persistenti e di utilizzare un tipo nullable (cioè non primitivo).

Tuttavia, i vantaggi dei primitivi non sono forti:

  1. Avere un valore non nullo incoerente in una proprietà è peggio di NullPointerException, poiché il bug in agguato è più difficile da tracciare: passerà più tempo da quando il codice è stato scritto fino a quando non viene rilevato un problema e potrebbe apparire in un contesto di codice completamente diverso rispetto a la sua fonte.
  2. Per quanto riguarda le prestazioni: prima di testare il codice, è generalmente una considerazione prematura. La sicurezza dovrebbe venire prima.

La documentazione di Hibernate (solo la prima versione che ho trovato) afferma:

La proprietà potrebbe essere stata chiamata nulla, e il suo tipo potrebbe essere stato qualsiasi tipo primitivo, qualsiasi tipo di "wrapper" primitivo, java.lang.String o java.util.Date.

...

Si consiglia di dichiarare le proprietà dell'identificatore con nome coerente nelle classi persistenti e di utilizzare un tipo nullable (cioè non primitivo).

Quindi la "voce dell'esperto" suggerisce l'utilizzo di Integer / Long ... ma non viene descritto il motivo per cui questo è il caso.

Mi chiedo se sia così che un oggetto che non è stato ancora persistito possa essere creato senza un identificatore (cioè con un valore di proprietà di null ), distinguendolo da entità persistenti.





primitive-types