Существуют ли веские причины для внутреннего хранения данных в формате XML?
https://stackoverflow.com/questions/1008564
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
За годы работы на своем месте я заметил отчетливую тенденцию к чему-то, что считаю антипаттерном:Сохранение внутренних данных в виде больших строк XML.Я видел, как это делалось разными способами, хотя два худших нарушителя были очень похожи.
Веб-сервис
Первое приложение, веб-служба, обеспечивает доступ к потенциально большому объему данных в базе данных SQL.При запуске он извлекает более или менее все эти данные из базы данных и сохраняет их в памяти в виде XML.(Три раза.) Владельцы этого приложения называют это кэшем.Я называю это медленным, потому что каждая проблема с производительностью, с которой сталкивались при работе с этим, напрямую связана с этой штукой.(Так как это корпоративная среда, неудивительно, что в сбое производительности обвиняют клиента, а не службу.) Это приложение действительно использует XML DOM.
Импортер
Второе приложение читает XML-файл, созданный в результате экспорта из сторонней базы данных.Цель состоит в том, чтобы импортировать эти данные в проприетарную систему (принадлежащую нам).Приложение, которое это делает, считывает весь XML-файл и сохраняет как минимум две, а иногда и четыре копии XML-файла на протяжении всей последовательности импорта.Обратите внимание, что данными можно манипулировать, преобразовывать и настраивать их до того, как произойдет импорт, поэтому импортер владеет этими данными в формате XML на протяжении всего их существования.Неудивительно, что этот импортер затем взрывается, когда предоставляется XML-файл среднего размера.Это приложение использует XML DOM только для одной из своих копий, все остальные представляют собой необработанные строки XML.
Моё понимание здравого смысла подсказывает, что XML – это нет хороший формат для хранения данных в памяти, но скорее данные должны быть преобразованы в XML при их выводе/передаче и преобразованы во внутренние структуры данных при чтении и импорте.Дело в том, что я постоянно сталкиваюсь с производственным кодом, который полностью игнорирует проблемы масштабируемости и проходит через тонна дополнительных усилий для этого.(Объем синтаксического анализа строк в этих приложениях пугает.)
Является ли это распространенной неспособностью применить правильный инструмент для работы, с которой сталкиваются и другие люди?Или это просто мое невезение?Или я упускаю что-то ослепительно очевидное и хороший ситуации, когда правильно и нормально хранить большие объемы данных в памяти в виде XML?
Решение
Все данные, хранящиеся в памяти, должны быть в классах. Чем выше объем данных, о которых мы говорим, тем важнее это становится. Xml - чрезвычайно раздутый формат, который снижает производительность. Xml следует использовать только для передачи данных между приложениями. ИМХО.
Другие советы
Нет, я согласен. Для вашего первого примера база данных должна обрабатывать почти все кэширование, поэтому хранить все данные в памяти программы неправильно. Это применимо, хранится ли оно в памяти в виде XML или иным образом.
Во-вторых, вы должны как можно скорее преобразовать XML в полезное представление, возможно, в базу данных, а затем работать с ним таким образом. Только если это небольшой объем данных, было бы целесообразно выполнять всю работу в памяти как XmlDocument (например, с использованием XPath). Разбор строк должен использоваться очень экономно.
@ Мэтью Флэшен делает замечательную мысль. Я хотел бы добавить, что когда вы присоединяетесь к любому существующему проекту, вы, скорее всего, найдете некоторые решения по проектированию и реализации, с которыми вы не согласны.
Мы все постоянно учимся чему-то новому и все совершаем ошибки. Хотя я согласен с тем, что это похоже на "дух" Я уверен, что другие разработчики пытались оптимизировать код с помощью концепции кеша.
Дело в том, что иногда требуется осторожный подход, чтобы убедить людей, особенно разработчиков, изменить свои пути. Это не проблема кодирования, а проблема людей. Вам нужно найти способ убедить этих разработчиков, что предлагаемые вами изменения не означают, что они некомпетентны.
Я бы предложил согласиться с ними, что кэширование может быть отличной идеей, но вы хотели бы поработать над этим, чтобы ускорить выполнение функций. Создайте небольшую демонстрацию того, как ваша (более логичная) реализация работает по сравнению со старым способом. Трудно спорить с резкими улучшениями скорости. Просто будьте осторожны с прямой атакой, как они реализованы в разговоре. Вам нужны эти люди, чтобы работать с вами.
Удачи!
Я тоже согласен, и я думаю, что есть элемент невезения.
... но хватаясь за соломинку, единственное использование, которое я видел для данных, хранящихся в формате XML, - это автоматизированные модульные тесты, где XML предоставляет простой способ макетировать тестовые данные. Определенно не стоит, однако.
Я обнаружил, что должен был сделать это, чтобы взаимодействовать с устаревшим COM-объектом. COM-объект может принимать либо xml, либо класс. Затраты на взаимодействие для заполнения каждого члена класса были слишком большими, и обработка xml была намного более быстрой альтернативой. Мы могли бы создать класс c #, идентичный классу COM, но это было слишком сложно сделать в наши сроки. Так что XML это было. Не то чтобы это когда-либо было бы хорошим дизайнерским решением, но когда речь шла о взаимодействии для огромных структур данных, это было самое быстрое, что мы могли сделать.
Я должен сказать, что мы используем LinqtoXML на стороне C #, поэтому с ним немного легче работать.
как насчет ООП и баз данных? Xml использует его, но могут быть проблемы (как вы видите) с его использованием для всего.
Базы данных могут включать индексацию, транзакции и т. д., которые ускорят доступ к вашим данным
С объектами в большинстве случаев проще работать, они дают лучшую картину вашего домена и т. д.
Я не против использования XML, но это похоже на шаблоны, они являются инструментами, которые мы должны понимать, где и когда их использовать, не влюбляться в них и пытаться использовать их везде ...
Грег,
в нескольких приложениях я более или менее точно следовал описанному вами шаблону:
Редактировать:не поцарапай это.Я никогда не сохранял XML в виде строки (или нескольких строк).Я просто разобрал его в DOM и поработал с ним.ЭТО было полезно.
Я импортировал источники XML в DOM (Microsoft Parser) и сохранил их там для всей необходимой обработки.Я хорошо знаю о накладных расходах памяти, которые вызывает DOM, но, тем не менее, я нашел этот подход весьма полезным.
Некоторые проверки во время обработки требуют произвольного доступа к данным.Для этой цели оператор selectPath работает очень хорошо.
Узлы DOM можно передавать туда и обратно в приложении в качестве аргументов.Альтернативой является написание классов, охватывающих каждый тип объекта, и их обновление по мере развития схемы XML.Это подход бедного человека (VB6/VBA) к полиморфизму.
Применить преобразование XSLT ко всему или частям DOM совсем несложно.
Файловый ввод-вывод также осуществляется DOM (xmldoc.save...)
Связанный список объектов будет занимать сопоставимый объем памяти и требовать больше кода.Всю функциональность поиска и ввода-вывода мне пришлось бы писать самому.
То, что я воспринимаю как антишаблон, на самом деле является более старой версией приложения, в которой XML более или менее вручную разбирался в массивы структур.
Для больших объемов данных ответ отрицательный, нет веских причин хранить данные непосредственно в виде XML-строк в памяти.
Тем не менее, вот интересный презентация Алекса Брауна о том, как сохранить XML в памяти более эффективным способом. Как «Ледяной поток».
Здесь также есть видео об этом и другие презентации, представленные на XML Prague 2009 здесь . .
В общем, я бы попытался использовать внутреннюю модель данных, которая не зависит от ее сериализации в XML.
Однако, по моему мнению, есть один случай, когда использование XML в качестве внутренней структуры данных имеет смысл : если ваша модель данных должна фиксировать иерархические отношения, формат которых может быть расширен сторонними организациями, и если ваш Приложение должно пересылать эти данные, сохраняя расширенную информацию.
Возьмем, к примеру, каркас регистрации дровосека . Идея состоит в том, чтобы иметь данные о событиях на основе XML модель, в которой каждое приложение может предоставлять иерархическую информацию о событиях (предупреждения, ошибки и т. д.). Фреймворк заботится о сборе событий и их распределении соответствующим обработчикам. Сторонний разработчик может легко определить свои собственные дополнения к формату и предоставить соответствующие генераторы и обработчики.
Важной частью здесь является то, что инфраструктура должна пересылать XML со всей информацией XML в целости от генератора к обработчику. В этом случае реализация внутренней структуры данных, которая собирает всю необходимую информацию, приводит к повторной реализации большей части самого XML. Следовательно, использование соответствующей структуры DOM для внутреннего представления данных имеет смысл.
