Usare una soluzione alternativa invece di andare nel modo "standard" nell'analisi di json

2

Sono stato incaricato di sviluppare un'applicazione java che include il recupero di una proprietà da una risposta JSON da un server Web.

Normalmente quando analizzo json passo con il modo standard di creare un modello pojo di json e poi uso la libreria gson di google per creare l'oggetto. Comunque questa volta sento che è eccessivo dover creare un pojo quando sto recuperando solo una proprietà da JSON, e voglio usare una soluzione che sarà solo unire e tagliare la stringa fino a che non rimarrò con la proprietà che io desiderare.

Quindi la mia domanda è, ci sarebbero dei lati negativi nel fare una simile soluzione alternativa invece di usare il metodo standard di usare un pojo e gson?

    
posta SteelToe 08.08.2017 - 01:35
fonte

5 risposte

23

Sì, c'è un lato negativo: bug nel parser mezzo cotto. Certo, JSON è semplice ma puoi comunque incontrare situazioni di fuga difficili.

Usa solo un metodo di analisi JSON provato e vero e salva le tue cellule cerebrali per i problemi più difficili.

    
risposta data 08.08.2017 - 01:50
fonte
9

Per evitare di creare una nuova classe Java che mappa la risposta JSON completa quando hai bisogno di un solo campo, puoi usare una libreria come JsonSimple che rappresenta un oggetto JSON analizzato con HashMap . È quindi possibile recuperare il valore di quella chiave da quella HashMap senza menzionare nient'altro che contiene.

    
risposta data 08.08.2017 - 13:48
fonte
4

Ottimizzazione prematura.

Lo svantaggio principale è il tempo perso in una soluzione fatta in casa.

In primo luogo, trascorrerai del tempo a sviluppare la soluzione e quindi a correggere i bug. Se ci sono bug, potrebbe non solo perdere tempo, ma anche il tempo dei tuoi colleghi: altri sviluppatori, tester, personale di supporto, ecc.

Quindi, chiunque debba leggere il proprio codice dovrà dedicare più tempo a capire cosa sta succedendo qui. Uno sa come deserializzare un JSON, ma nessun'altra persona conoscerà il tuo approccio.

Idealmente, i requisiti non cambieranno mai e il tuo codice non dovrà essere modificato. Nella vita reale, tuttavia, le cose potrebbero non andare bene. Se cambiano i requisiti (come dover deserializzare altri campi o adattare il tuo codice a una modifica della struttura JSON), potrebbero passare a cascata più tempo per gli sviluppatori, più codice, più bug.

Diciamo che sei molto veloce e davvero bravo. Hai finito di implementare la tua soluzione in un'ora. Qual è il tuo salario orario? Ora in termini di cicli di CPU salvati, quanto risparmia la tua soluzione personalizzata al tuo datore di lavoro? Ottieni l'immagine.

    
risposta data 08.08.2017 - 14:39
fonte
1

Il lato negativo è che il tuo codice genererà delle eccezioni quando tenterai di accedere a una proprietà che non esiste, piuttosto che quando tenterai di analizzare il json.

Ho molta simpatia per il tuo dilemma. Ho dovuto consumare un modello JSON da una presa grafica in c #

Sono andato nel modo normale di creare classi per abbinare l'oggetto solo per scoprire che lo scrittore dell'app per grafici aveva completamente utilizzato la "capacità" di JavaScript di non scrivere con forza.

Ciò ha comportato l'impossibilità di ricreare il modello in quanto la proprietà X potrebbe essere uno dei 5 diversi modelli aventi ciascuno i propri oggetti secondari, anch'essi diversi.

Fortunatamente c # ora ha la classe dynamic che ero in grado di utilizzare. Non credo però che java abbia un equivalente. Forse potresti deserializzare su una Hashtable nidificata?

    
risposta data 08.08.2017 - 10:31
fonte
1

Una libreria di analisi JSON compatta è JSON-java . Non si associa alle classi POJO, ma fornisce una rappresentazione navigabile del JSON analizzato. È autonomo, il che significa che non dipende da altre librerie (un fatto che mi piace molto). L'ho usato un paio di volte quando un vero e proprio mapper JSON / POJO mi sembrava eccessivo.

    
risposta data 08.08.2017 - 21:21
fonte

Leggi altre domande sui tag