Usa oggetti JSON o POJO nel servizio back-end?

Di solito è una buona idea separare il metodo di serializzazione (JSON) dalla tua logica aziendale in modo che se in futuro deciderai di utilizzare qualche altro tipo di serializzazione, puoi farlo senza influire sulla logica di business.

Jackson è probabilmente la libreria open source più popolare per la serializzazione / deserializzazione JSON in Java.

Nella situazione in cui è necessaria una certa quantità di trasformazione tra i dati ricevuti dal database dei clienti e ciò che effettivamente si restituisce al chiamante, di solito creo una classe DTO (data transfer object) separata che contiene solo i campi da serializzato.

D'altro canto, se hai sempre bisogno di rimuovere gli stessi campi dai dati del cliente prima della trasmissione e non ti dispiace inserire annotazioni specifiche per la serializzazione sui tuoi POJO, puoi usare Jackson's @JsonIgnore (o simile) su quei campi e salta il DTO.

Io sceglierei la soluzione più semplice e semplice che coprirà il tuo attuale requisito.

Come hai detto, tutto quello che ti serve è rimuovere due campi, json manipulation è sufficiente ed è molto semplice.

In futuro, se credi che si tratti di trasformazioni più complesse (che non sono facili da fare con json manipulation) puoi facilmente aggiungere DTO nel mezzo e fare le trasformazioni. Dal momento che stai ottenendo json e l'invio di json aggiungendo DTO non interesserà nessuno dei sistemi esterni.

È un classico compromesso Prestazioni + facilità d'uso contro scalabilità e flessibilità.

I POJO sono altamente perfomanti e molto facili da usare in un programma Java. MA sono limitati a una singola VM. Non è possibile passare un POJO a un'altra macchina virtuale oa un altro server oa un altro processo non implementato in Java. Per passare il POJO a un programma Java in un'altra VM è necessario serializzare il POJO e de-serializzarlo nel processo di ricezione. I metodi di serializzazione Java predefiniti sono storicamente molto dipendenti dalla versione di Java utilizzata.

I messaggi formattati JSON possono essere passati tra processi, tra server, e possono essere facilmente letti dai programmi Java ma anche da Javascript, php, python C, C ++ ecc.

Altri vantaggi dell'utilizzo di un JSON (o XML :-)) includono la facilità del debug (basta leggere il messaggio) e la facilità di test (è banale creare un archivio e copiare i messaggi JSON da utilizzare in un framework di test).

Sono d'accordo sull'approccio più semplice in genere è il migliore e per me la manipolazione JSON ha vinto le mani in questa situazione.

Il bit importante della domanda è '(rimuovendo alcuni campi che non sono rilevanti) al client mobile'

Quindi da quello che ho capito c'è più di una variante di client mobile e per ogni diverso campo json sono selezionati dai dati dei clienti di origine json.

Utilizzando l'approccio DTO, dovrei prima eseguire il marshalling dei dati del cliente di origine JSON su un DTO, quindi se avessi 4 client mobili avrei bisogno di 4 DTO e più metodi per impostare gli attributi su ciascun tipo di DTO.

Utilizzando l'approccio JSONObject, avrei qualcosa del tipo:

JSONObject sourceCustomerData = JSONObject.fromObject(httpResponseInputStream)

e passerebbe il sourceCustomerData a un metodo per restituire il JSON adatto al singolo client mobile, ad esempio:

JSONObject customerDataClientX = getRequiredJson(requiredJsonFeildsForMobileClientA, sourceCustomerData) 

dove requiredJsonFeildsForMobileClientA è l'elenco dei campi JSON richiesti. Pertanto, per ogni client mobile può essere passato un elenco diverso di campi JSON richiesti.

DTO PROS - Diritto in avanti e codice verboso POJO. - Adatto per trasformazioni più complesse. - Facilmente testabile.

DTO CONS - I DTO sono modelli tenuti in codice, non possono essere modificati senza manipolare il codice. - Più codice come DTO e il codice della popolazione sono direttamente correlati al numero di varianti del client mobile.

JSONObject PROS
- Codice straight forward. - Facilmente testabile, è una funzione su fattori esterni. - Meno codice come una scarpa adatta a tutti, non direttamente correlato al numero di varianti di client mobili
- Non esiste un modello contenuto nel codice, l'elenco dei campi JSON per ogni client mobile può essere tenuto in configurazione esternamente.

JSONObject CONS
- Non adatto a trasformazioni più complesse. - JSONObject richiede il modello di navigazione JSON, non così bello da preparare o scrivere.

In futuro, poiché sono necessarie trasformazioni più complesse, è possibile aggiungerle e persino prendere in considerazione la possibilità di passare a un modello basato su DTO se rende l'attività più semplice.