C'è qualche API disponibile per rappresentare varie unità di articoli come KG, Litro, Metro, KM, ecc.

Question

Nel mio progetto, da qualche parte devo lavorare con un unitOfIssue di Items. Ora, vari elementi possono avere diverse unità di rappresentazione. Quindi, stavo cercando qualche API o un modo, per gestire elegantemente questa situazione.

C'è qualche API disponibile, che fornisce un modo per rappresentare queste unità? Ho sentito parlare di JScience che sembra impressionante, ma ancora una volta sto affrontando un altro problema con la mappatura in JPA. Dopo un po 'di lavoro su Google, ho scoperto che in questo contesto si sta verificando un po' di lavoro come - JScience-JPA, ma sembra che non sia ancora stabile da utilizzare in produzione.

Ho anche trovato qualcosa su JSR-275, ma da this JCP page sembra che sia stato rifiutato.

Poi mi sono imbattuto in unitsofmeasure, che non ho ancora scavato nei dettagli. Ma, di nuovo, arriva lo stesso problema. Questo può essere mappato con JPA?

Edit: - Da this SO question mi sono imbattuto in Java Numbers with Unit ma non so se è pronto per la produzione o meno.

Sono davvero confuso, specialmente dopo aver visto quelle opzioni sopra. E JPA è un'ulteriore preoccupazione sul fatto che io possa usarne qualcuna o no. Qualcuno ha mai affrontato un tale tipo di situazione e trovato una via d'uscita? Ho davvero bisogno di aiuto qui. Cosa dovrei usare? E se non c'è altra via d'uscita, quale sarebbe il modo appropriato di rappresentare queste unità. Un modo che vedo è usando enums. ma, naturalmente, quella sarebbe stata l'ultima scelta.

Answer 1

Ti suggerisco di scriverne uno tuo. Probabilmente potresti aver bisogno anche di Unit Of Measure Conversion.

Definizione UOM da ARTS Retail Data Model Logical View

e per la conversione

Answer 2

ero in un progetto in cui abbiamo avuto ampio uso di JSR-275 (prima che venisse respinto da JCP). Inizialmente non stavamo usando JPA, ma in seguito è stato deciso che dovremmo mantenere il nostro modello usando JPA 2.0 e ho dovuto occuparmi della persistenza dei miei oggetti di misura.

Questa potrebbe non essere la risposta alla tua domanda, ma potrebbe portare alcuni pensieri interessanti alla discussione.

Abbiamo preso in considerazione diverse alternative:

1. misure sono state serializzabile, e JPA può mappare qualsiasi oggetto serializzabile. Il problema qui è che le misure sarebbero salvate come oggetti binari nel database e sarebbero soggette a tutti i problemi di serializzazione (es. Versioning, ecc.)
2. Potremmo adattare il nostro modello mantenendo i dati in tipi non elaborati (cioè interi, doppi, ecc.) a condizione che siamo d'accordo sull'utilizzo dell'unità di misura internazionale per ogni unità. Pertanto, i campi sarebbero basati su tipi supportati da JPA, ma i getter e i setter userebbero gli oggetti indicatore. Configurare il mapping JPA in base ai campi, non alle proprietà.Il problema qui era dover modificare il modello per modificare i dati incapsulati senza influire sull'interfaccia pubblica degli oggetti del dominio.
3. Dato che stavamo usando la modalità di ibernazione come nostro fornitore di persistenza, potremmo accettare di deviare dallo standard JPA e usare hibernate custom value types per mappare gli oggetti di misura sui corrispondenti tipi primitivi. Quindi potremmo mappare i nostri tipi usando le annotazioni di ibernazione per questo scopo. (See an example here). L'avvertimento in questo sta perdendo l'indipendenza del venditore di persistenza.

Abbiamo finito per utilizzare l'alternativa n. 3 e ha funzionato abbastanza bene per noi.