Dlaczego osadzanie JSON w XML jest złe?

Mój gut mówi, że umieszczenie jednego formatu w drugim jest błędne, ale nie mogę wymyślić konkretnych powodów.Dlaczego osadzanie JSON w XML jest złe?

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

versus tylko wprowadzenie go w xml

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

Obie sekcje są logicznie będzie analizowany przez innego kodu, ale jako format wymiany danych, to jest ok, aby wymieszać i składnia mecz?

Czy odpowiedź zmienia się, jeśli mamy istniejący punkt końcowy, który analizuje odpowiedź JSON? Będziemy musieli przekodować ten punkt końcowy do przetwarzania XML.

Źródło

2009-07-23 Paul Tarjan

Dlaczego przechowywanie plików sqlite jako obiektów typu blob w bazach danych jest złe? –

Jako format wymiany za pomocą dwóch formatów stanowi dodatkowe obciążenie dla osób, które chcą z tobą współpracować. Teraz trzeba mieć parser XML i parser JSON.

Utrudnia to również grokowanie w formacie, ponieważ muszą oni mentalnie zmieniać biegi, myśląc o różnych częściach pliku.

Wreszcie, nie będzie można łatwo zrobić rzeczy, które wyglądają na całą strukturę na raz. Na przykład nie można używać XPath do pobierania bitów JSON, ani nie można traktować całej odpowiedzi jako obiektu JavaScript. Łącząc dwa formaty, pojawia się problem "najgorszego z obu światów", jeśli chodzi o manipulowanie danymi.

Źródło

2009-07-23 00:23:20

Czy twoja odpowiedź zmienia się, jeśli mamy istniejący punkt końcowy, który analizuje odpowiedź JSON? Będziemy musieli przekodować ten punkt końcowy do przetwarzania XML. –

Ponieważ masz już rozwiązanie - tj; parser JSON na parser XML - wtedy odpowiedzi na twoje pytanie będą dotyczyły przenośności, czytelności, łatwości konserwacji i prostego, staromodnego smaku. Pewnie, że teraz działa * teraz *, ale pomyśl o tym, kto może ją przeczytać w przyszłości, do kogo możesz przekazać XML, jak wytłumaczysz im, dlaczego potrzebujesz parsera JSON na końcu i tak dalej. Wygląda na to, że odkładasz teraz pracę, co może spowodować, że więcej pracy powstanie później. – shuckster

@Paul: Jeśli to działa dla twojej obecnej implementacji, nie ma powodu, aby go teraz zmieniać. Jednak jeśli zaczniesz wymyślać twórcze (czytaj: śmierdzące) sposoby na obejście problemów, które Laurence opisał, to wtedy, gdy chcesz trzymać się jednego lub drugiego. –

To trochę jak debata na temat normalizacji baz danych. Czystsze i bardziej eleganckie jest robienie wszystkiego w czystym formacie XML (lub normalizowanie schematu bazy danych), dzięki czemu nie musisz niepotrzebnie łączyć się z konkretną implementacją. Ale jeśli musisz przekonwertować XML na obiekty JavaScript (lub dołączyć 5 tabel dla każdego przeklętego SELECT), możesz skończyć pisanie wielu dodatkowych kodów i ponosić niepotrzebne trafienia wydajnościowe.

Wszystko zależy od tego, jak zachować równowagę między wygodą a poprawnością formalną. Jeśli jest to format wymiany XML, który będzie standaryzowany przez W3C i użyty przez miliony, to dobry Boże, nie używaj JSON. Jeśli jest to aplikacja wewnętrzna, która będzie przetwarzana tylko przez kod, sam napiszesz, a następnie wkręć, po prostu wrzuć tam JSON i ruszaj dalej!

Źródło

2009-07-23 00:26:01

+1. dobre praktyki są dobre. ale nie mogą zastąpić dobrego myślenia. czasami znane wzorce nie są najlepszym rozwiązaniem problemu. czasem włamanie jest słuszne. cokolwiek robisz, wiesz DLACZEGO to robisz, a im bardziej jest on brudny, tym więcej potrzebujesz do udokumentowania go i enkapsulacji gdzieś w mesie, więc możesz z łatwością go wymienić pewnego dnia ... :) – back2dos

Moim zdaniem XML jest preferowaną reprezentacją transferu danych, ale JSON jest znacznie bardziej wyrazisty, jeśli chodzi o Mapy i tablice. Nie miałbym problemu z osadzeniem JSON-a w xml w celu reprezentowania listy lub mapy.

Źródło

2011-06-29 14:19:15

Dlaczego osadzanie JSON w XML jest złe?

Odpowiedz

Powiązane problemy