Я размышлял над аналогичной необходимостью выбора общего представления для разговоров (транспортного контента) между моими клиентами и серверами через шаблон фасада. Я хочу, чтобы представление было стандартизированным, читабельным (кратким), надежным, быстрым. Я хочу, чтобы он был легким в реализации и запуске, простым в тестировании и простым в переноске. Обратите внимание, что я уже удалил XML по своему определению и с явным намерением.
Под "переносом" я подразумеваю, что я хочу поддерживать другие представления транспортного контента, такие как XML, SOAP, возможно, свойства Java или форматы Windows INI, значения через запятую (CSV) и т. форматы, патентованные двоичные форматы, такие как книги Microsoft Excel, и все остальное, что может прийти. Я реализовал бы эти вторичные представления, используя обертки / декораторы вокруг основного фасада. Каждое из этих вторичных представлений желательно, особенно для интеграции с другими системами при определенных обстоятельствах, но ни одно из них не является желательным в качестве основного представления из-за различных недостатков (неспособность соответствовать одному или нескольким моим критериям, перечисленным выше).
Поэтому до сих пор я выбираю формат JSON в качестве основного представления транспортного контента. Я намерен подробно изучить этот вариант в ближайшем будущем.
Только в случаях экстремальных соображений производительности я мог бы пропустить перевод основного традиционного формата. Преимущества чистого дизайна включают в себя хорошую производительность (без лишних усилий, простоту обслуживания), для которой достойный выбор оборудования должен быть единственным необходимым дополнением. Когда производительность становится чрезвычайно высокой (например, обработка сорока тысяч входящих файлов данных на общую сумму сорок миллионов транзакций в день), тогда ВСЕ нужно пересматривать в любом случае.
Как разработчик, администратор баз данных, архитектор и многие другие, я создал системы практически любого размера и описания. Я уверен в своем выборе критериев и с нетерпением жду подтверждения его пригодности. В самом деле, я надеюсь опубликовать реализацию как open-source (но пока не затаив дыхание).
Обратите внимание, что в этом обсуждении проекта игнорируется транспортная среда (HTTP, SMTP, RMI, .Net Remoting и т. Д.), Которая является преднамеренной. Я считаю, что гораздо эффективнее рассматривать транспортную среду и транспортный контент как совершенно отдельные конструктивные соображения друг от друга и от рассматриваемой системы. На самом деле, я намерен сделать их практически «подключаемыми».
Поэтому я призываю вас строго рассмотреть JSON. С наилучшими пожеланиями.