Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

При проектировании .NET Compact Framework ставилась цель найти разумный компромисс между двумя проектными ограничениями. Необходимость сведения к минимуму размера NET Compact Framework (объем установленного на устройстве программного обеспечения не должен был превышать 2 Мбайт) вступала в противоречие со стремлением предоставить разработчикам как можно более широкие функциональные возможности. В процессе поиска компромиссных решений степень полезности тех или иных средств и необходимость в них тщательно взвешивались с точки зрения соответствующего увеличения размера .NET Compact Framework. Исходя из этих соображений и было решено, что в первом выпуске NET Compact Framework средства XPath и XSLT поддерживаться не будут.

XPath — это язык запросов, используемый для проведения поиска в XML-документах. Этот язык предоставляет очень широкие возможности поиска, но отличается сложностью, и для его эффективного использования требуется значительная вычислительная мощность. XSLT — это технология преобразования дерева XML-документа в новый документ в соответствии с определенными правилами; эту технологию часто применяют для преобразования XML-данных в HTML-документы. Для его эффективного функционирования также требуются значительные вычислительные ресурсы.

Полезность обоих указанных средств совершенно очевидна, и каждому разработчику хотелось бы иметь их в своем распоряжении, но было ли бы уместным их применение в случае мобильных приложений, выполняющихся на устройствах в условиях дефицита ресурсов? Поддержка XSLT и XPath лишь привела бы к напрасному увеличению размера .NET Compact Framework, поскольку предоставляемые разработчику функциональные возможности не могли бы эффективно использоваться во многих задачах, для которых они предназначены. Именно из этих соображений и было решено не включать поддержку XPath и XSLT в версию 1.1 .NET Compact Framework.

Не исключено, что поддержка этих средств появится в последующих версиях .NET Compact Framework; в частности, существует настоятельная потребность в поддержке XPath. Однако разработчикам следует хорошенько подумать о том, с какими трудностями им придется столкнуться, если они решатся на использование пусть и ценных, но весьма требовательных в отношении необходимых вычислительных ресурсов библиотек. Обычно считается, что встроенные средства среды выполнения должны нормально функционировать при любых обстоятельствах, однако это далеко не так. Вспомните данные ранее в этой главе рекомендации относительно необходимости тщательно взвешивать достоинства и недостатки удобного, но требующего использования обширной информации о состоянии подхода, основанного на модели XML DOM, и более сложного, но менее зависимого от состояния подхода, основанного на однонаправленном доступе к данным с помощью объектов XMLReader и XMLWriter; руководствуйтесь этими же советами и тогда, когда возникает проблема выбора зависящей от состояния или требовательной к ресурсам библиотеки. Вы можете использовать такую библиотеку, но всегда оценивайте, с какими дополнительными расходами это будет сопряжено, и проводите соответствующие измерения.

XML — это формат данных, который является в высшей степени полезным как для хранения специфических для приложения данных, так и для обмена информацией между приложениями. Он обеспечивает достижение разумного компромисса между простотой и гибкостью текстовых файлов и строгостью баз данных. В том, что сфера применения XML на серверах, настольных компьютерах и мобильных устройствах будет только расширяться, не может быть никаких сомнений.

Одним из важнейших высокоуровневых проектных решений является решение относительно того, какой формат данных следует выбрать для конкретной коммуникационной задачи — XML или двоичный формат. Применение XML сулит значительные преимущества, но эти преимущества даются за счет увеличения размеров приложений и повышения требований к доступным на устройстве ресурсам. Во многих случаях дополнительные накладные расходы вполне окупаются достигаемыми преимуществами, а хорошая проработка проекта может обеспечить приемлемое функционирование устройства. В то же время, в случае данных большого объема или при работе с узкополосными соединениями следует рассматривать в качестве альтернативного решения двоичные форматы. Наиболее оптимальный подход — это количественная оценка эффектов использования бинарных форматов и XML в реальных ситуациях и принятие проектных решений, исходя из необходимости создания наиболее комфортных условий работы для конечного пользователя. Если проектными решениями и настройкой приложения добиться эффективного функционирования варианта реализации, основанного на использовании XML, не удается, то может потребоваться использование двоичных форматов или внесение изменений в коммуникационную модель.