2009-07-23 11 views
15

Il mio istinto mi dice che inserire un formato in un altro è sbagliato, ma non riesco a trovare ragioni concrete.perché l'incorporamento di JSON in XML è errato?

<root> 
<stuff> 
    thing 
</stuff> 
<more> 
    <[!CDATA[{"a":["b","c"]}]]> 
</more> 
</root> 

contro solo metterlo in xml

<root> 
<stuff> 
    thing 
</stuff> 
<more> 
    <a> 
    b 
    </a> 
    <a> 
    c 
    </a> 
</more> 
</root> 

Le due sezioni sono logicamente sta per essere analizzato da codice diverso, ma come formato di interscambio, è ok per mescolare e sintassi partita?

La risposta cambia se abbiamo un endpoint esistente che analizza la risposta JSON? Dovremmo ricodificare questo endpoint per l'ingestione XML.

+5

Perché la memorizzazione di file sqlite come blob nei database è danneggiata? –

risposta

21

Poiché un formato di interscambio che utilizza due formati comporta un onere aggiuntivo per le persone che desiderano interagire con voi. Ora hanno bisogno di avere un parser XML e un parser JSON.

Inoltre rende più difficile per le persone ingannare il formato, in quanto devono cambiare mentalmente gli ingranaggi quando si pensa a diverse parti del file.

Infine, non sarà possibile eseguire facilmente le operazioni che guardano l'intera struttura contemporaneamente. Ad esempio, non puoi usare XPath per afferrare i bit JSON, né puoi trattare l'intera risposta come un oggetto JavaScript. Miscelando due formati si ottiene un problema "peggiore dei due mondi" quando si tratta di manipolare i dati.

+1

La tua risposta cambia se abbiamo un endpoint esistente che analizza la risposta JSON? Dovremmo ricodificare questo endpoint per l'ingestione XML. –

+0

Dal momento che hai già una soluzione - vale a dire; un parser JSON su un parser XML - quindi le risposte alla tua domanda saranno relative alla portabilità, leggibilità, manutenibilità e semplice gusto vecchio stile. Certo funziona * ora *, ma pensa a chi potrebbe leggerlo in futuro, a chi potresti trasmettere l'XML, a come spiegheresti perché hanno bisogno di un parser JSON alla fine e così via. Sembra piuttosto che tu stia rinunciando al lavoro per ora, il che potrebbe comportare la creazione di molto più lavoro in seguito. – shuckster

+1

@Paul: se funziona per l'implementazione corrente, non c'è motivo di cambiarlo subito. Tuttavia, se inizi a inventare dei modi creativi (leggi: puzzolenti) per aggirare i problemi che Laurence ha descritto è quando vuoi restare con uno o l'altro. –

7

È un po 'come il dibattito sulla normalizzazione del database. È più pulito e più elegante fare tutto in puro XML (o normalizzare lo schema del database), in questo modo non sei inutilmente associato alla tua particolare implementazione. Ma se devi convertire gli oggetti XML in JavaScript (o unirti a 5 tavoli per ogni dannato SELECT), potresti finire per scrivere un sacco di codice in più e incorrere in risultati di prestazioni non necessari.

Tutto dipende da come si bilancia la praticità con la correttezza formale. Se questo è un formato di interscambio XML che sarà standardizzato dal W3C e utilizzato da milioni allora caro Dio, non usare JSON. Se questo è per un'app in-house che verrà elaborata solo dal codice che tu stesso hai scritto, poi fanculo, butta lì il JSON e vai avanti!

+5

+1. le buone pratiche sono buone. ma non possono sostituire il buon modo di pensare. a volte, i pattern non sono la soluzione migliore per un problema. a volte un hack è la cosa giusta. qualsiasi cosa tu faccia, sappi perché lo fai, e più è confuso, più devi documentarlo e incapsulare il disordine da qualche parte, così puoi facilmente sostituirlo un giorno ... :) – back2dos

3

A mio parere, XML è la rappresentazione di trasferimento dati preferita, ma JSON è molto più espressivo quando si tratta di Maps e Arrays. Non avrei alcun problema con l'incorporamento di JSON in xml per rappresentare un elenco o una mappa.

Problemi correlati