Как наиболее эффективно читать удаленный XML-файл?
Я разрабатываю небольшое приложение, которое извлекает файл XML, расположенный на удаленном сервере (http://xxxx.com/myfile.xml) Этот файл относительно большой, и он содержит большой список геолокаций с другой информацией, которую мне нужно использовать для моего приложения. Итак, я один раз прочитал этот файл удаленно и вставил его в небольшой файл SqlCE (database.sdf)
Итак, если мне нужно получить доступ к геолокации №1, я просто сделаю оператор SELECT в этой БАЗЕ ДАННЫХ вместо того, чтобы каждый раз загружать весь XML-файл.
Но я хотел бы знать, можно ли это сделать без использования файлов .sdf?
Какой способ самый эффективный (самый быстрый)?
Сохранение большого файла XML один раз локально и загрузка, если каждый раз, когда я запускаю свое приложение, загружать его в набор данных? это сделало бы приложение немного длинным, чтобы загружаться каждый раз
Сохранение большого файла XML один раз локально и чтение узлов один за другим для поиска геолокации №1?
Или возможно получить геолокацию № 1 с удаленного xml напрямую (http://xxxx.com/myfile.xml) без чтения всего файла?
У тебя есть другие идеи?
Благодарность
Ответы 3
Загрузите большой XML-файл, преобразуйте его в подходящую другую структуру данных, сохраните в файл в эффективном формате. (XML действительно не очень эффективен.)
Я считаю, что реализация Буферы протокола Марка Грейвелла работает на Compact Framework ...
(Ни одна из реализаций protobuf еще не считается готовой к производству, но пара близка к этому. Нам нужны тестеры!)
Буферы протокола - это в основном протокол двоичной сериализации. Да, вам нужно будет загрузить файл, но он будет небольшим (PB эффективен в пространстве) и быстрым (парсеры PB эффективны во времени). Если вы не хотите изменить саму сборку, вам придется откуда-то загружать данные!
Что касается protobuf-net, на данный момент нет отдельной загрузки для версии CF, но в исходном коде есть csproj для CF 2.0 и CF 3.5.
Чтобы уточнить ваш вопрос; на самом деле protobuf-net даже не использует файл .proto (на данный момент); файл .proto просто описывает, что такое данные - protobuf-net просто смотрит на ваши классы и выводит из них схему (аналогично тому, как работают XmlSerializer / DataContractSerializer и т. д.). Таким образом, существует является, а не .proto - просто классы, которые выглядят как ваши данные.
Однако, прежде чем вы приступите к созданию классов, которые выглядят как ваши данные, мне интересно, не могли бы вы просто использовать GZIP или [PK] ZIP для сжатия данных и передачи их «как есть». Xml вообще хорошо сжимает очень. Конечно, тогда становится проблемой найти реализацию GZIP (и т. д.) Для CF.
Конечно, если вы хочу используете здесь protobuf-net, я с радостью посоветую и т. д., Если у вас возникнут проблемы ...
Другой вариант - ваше приложение CF вызовет веб-службу, у которой есть данные локально ...
большое спасибо за информацию. На самом деле меня больше всего беспокоит скорость, а не размер (скорость загрузки приложения и извлечения геолокации №X из файла). И из того, что я читал о выступлениях, protobuf-net должен помочь. PS: я использую CF.NET 3.5,
Это хорошо; версия CF 3.5 имеет некоторые оптимизации (связанные с делегатами), которые версия CF 2.0 не может использовать.
Пока ... мне нравится ProtoBuf ... Пока я тестирую только на своем рабочем столе, но его довольно легко использовать (с примером в SVN Trunk). Мне еще нужно попробовать CF.NET, но, похоже, это именно то, что мне нужно. Отличная работа !
Я рад, что у тебя все в порядке. Если у вас возникнут какие-либо проблемы, напишите мне по электронной почте (меня легко найти ...) или через сайт PB.
Зачем вам для этого перетаскивать весь файл на CE-устройство? Это трата полосы пропускания, и, безусловно, поиск на встроенном процессоре будет на путь медленнее, чем на сервере, независимо от формата хранения. У вас должна быть служба (веб, WCF или что-то еще), которая позволяет вам запрашивать единую геолокацию, которую вы хотите.
да, мне хотелось бы, чтобы не было веб-сервиса ... но XML-файл создается не мной, а третьим лицом. Так что, пока они не создадут веб-сервис, я придерживаюсь этого решения. Но буфер протокола до сих пор является лучшей альтернативой, которую я пробовал (быстрее, чем файл sdf или каждый раз анализирует xml)
Спасибо, это интересно. Но я не могу найти версию Compact Framework (нашел только 2/3 / Silver). Итак, если я хорошо понял, эти «Буферы протокола» используются для кодирования структурированных данных в файл «.prot»? Но тогда это будет означать, что мне все равно придется загружать этот файл .prot каждый раз, когда я запускаю приложение?