Программирование для Silverlight с помощью CoreCLR - Библиотека базовых классов

ОГЛАВЛЕНИЕ

Библиотека базовых классов

Развитие .NET Framework в настольной среде позволило ей удовлетворять нужды и пользователей, и серверов. Поэтому в библиотеке базовых классов (Base Class Library – BCL) имеется масса функций, лишенных смысла при работе с веб-клиентами. Например, поскольку Silverlight не поддерживает CAS, значительная часть System.Security является ненужной. Многие другие классы, вроде System.Console, нет смысла применять в сети. (Зачем же тогда мы включили урезанный класс System.Console? Он помогает нам тестировать продукт.)

Наша цель в случае библиотек идентична таковой для базового механизма: урезание до минимально возможного набора функций, который позволил бы разработчикам .NET успешно работать, не изучая совершенно новой технологии. Определенное вдохновение и руководство нам дала .NET Compact Framework, которая столкнулась с той же проблемой в иной ситуации. При доводке BCL для Silverlight мы также сохранили совместимость между .NET Compact Framework и Silverlight. Наличие одной библиотеки для всех платформ позволяет довести до максимума универсальность навыков, связанных с .NET.

В BCL имеется ряд мест, где можно найти продублированные функции. Порой функции дублируются внутри самой BCL – как в случае универсальных и неуниверсальных коллекций. Порой функции уже существуют в базовой ОС, как в случае поддержки глобализации. Поддерживать каждую альтернативу в библиотеке базовых классов Silverlight не только нет необходимости – вычеркивание такого дублирования поведения дает выигрыши в производительности и единообразии.

С тех пор, как мы внедрили поддержку универсальных коллекций в .Net Framework версии 2.0, мы выступали за переход на них. В версии среды 1.x структуры данных общего назначения приходилось основывать на объектах, чтобы тот же базовый класс структуры данных можно было использовать для создания различных типов коллекций. С помощью параметров универсального типа компилятор может расширить эти структуры данных общего назначения, чтобы обеспечить безопасность типов, упрощая тем самым написание и обслуживание кода. Вдобавок, универсальные коллекции обычно работают на типах значений лучше, чем неуниверсальные, благодаря отсутствию потребности в элементах окон. В целом, универсальные коллекции предоставляют все функции неуниверсальных. А поскольку дублирование излишне, мы не включали неуниверсальные коллекции, вроде ArrayList, в библиотеку базовых классов Silverlight.

Все знакомы по крайней мере с некоторыми проблемами глобализации: во многих европейских странах запятая используется в качестве разделителя дробной части; в китайском числа группируются в четверки (1000,0000) и так далее. В платформе .NET Framework функции глобализации реализуются внутренне, чтобы иметь возможность правильно работать в различных культурах. Для этого в нее входят данные глобализации для всех поддерживаемых культур, позволяя предназначенным для .NET приложениям вести себя единообразно во всех поддерживаемых версиях Windows. Однако у этого есть свои недостатки. В CLR должны входить большие таблицы данных, и данные часто становятся устаревшими с течением времени. Вдобавок, данные имеют отношение только к Windows, так что данные для некоторых культур .NET отличаются от тех же культур в Mac OS X. По этим причинам в состав CoreCLR не входит собственных данных глобализации. Вместо этого System.Globalization.CultureInfo использует функции глобализации, предоставленные размещающей ОС. Таким образом, приложения Silverlight будут вести подобно приложениям Mac на Mac OS X и подобно приложениям Windows на Windows.

В целом, мы попытались обеспечить схожую контактную зону интерфейсов API между CLR, .NET Compact Framework и Silverlight, но по BCL рассеяны другие мелкие различия. Например, поскольку Silverlight имеет единственный поток интерфейса пользователя, у него имеется единственный объект Dispatcher, содержащий очередь рабочих элементов для интерфейса пользователя. Использование Dispatcher позволит обновлять интерфейс пользователя из не относящегося к нему потока. Данный код позволит обновить элемент интерфейса пользователя (MyListBox) с помощью коллекции, созданной в другом потоке (скажем, в фоновом потоке):

MyListBox.Dispatcher.BeginInvoke(() => MyListBox.ItemsSource = MyItems);  

Мы рекомендуем использовать System.ComponentModel.BackgroundWorker в Silverlight, поскольку он инкапсулирует обновление интерфейса пользователя по завершении, но с целью совместимости мы всё же включим низкоуровневые потоковые интерфейсы API, такие как System.Threading.ThreadPool.QueueUserWorkItem и System.Threading.Monitor.Enter.

Подобно модели прозрачности безопасности, некоторые из функций, новых для библиотеки базовых классов Silverlight, уже появлялись в предыдущих версиях .NET Framework. Хорошим примером этого является изолированное хранилище, предоставляющее виртуализованную систему файлов приложениям, помещенным в «песочницу». Оно существовало со времен .NET Framework 1.0, но всегда затрагивало ограниченный набор ситуаций. Silverlight концентрируется на приложениях в «песочнице» и может использовать изолированное хранилище в полной мере: 

using (IsolatedStorageFile isoStore = 
IsolatedStorageFile.GetUserStoreForApplication())
{
using (StreamWriter writer = new StreamWriter(isoStore))
{
writer.Write("This is an isolated storage file.");
}
}

Подобно файлам cookie в веб-обозревателе, изолированное хранилище позволяет приложениям Silverlight поддерживать одинаковость состояния между вызовами. Однако изолированное хранилище предоставляет полную, виртуализованную файловую систему, поддерживающую создание каталогов и файлов. Хотя изолированное хранилище и не предназначено для хранения ценной информации, такой как пароли, местоположение хранилища скрывается, и доступ в него дается только приложению, владеющему хранилищем.

Квоты для изолированных хранилищ определяются группами приложений, которые основаны на доменном имени приложения Silverlight. Например, два приложения Майкрософт, расположенных в каталогах microsoft.com, будут входить в одну группу приложения, а это значит, что они будут делить одну квоту. По умолчанию группе приложений дается 1 МБ пространства.

Однако, если приложение нуждается в дополнительном пространстве для хранения, оно может запросить большую квоту, запросив пользователя с помощью диалогового окна, которое, для примера, укажет, что microsoft.com желает увеличить свою квоту до 8 МБ. Пользователи могут включать или отключать изолированные хранилища, а также удалять текущие случаи их использования в диалоге настройки Silverlight (в диалоге оно именуется Application Storage («Хранилищем приложения»)). Группы приложений также могут иметь общие хранилища, что позволяет связанным приложениям делиться данными.

Хотя изолированные хранилища существуют не первый день, их использование никогда не было так заманчиво, как в случае Silverlight. Настраиваемая, безопасная система файлов для интерактивных веб-приложений позволяет разрабатывать традиционные офисные приложения, такие как текстовые редакторы, или приложения, обслуживающие большие объемы данных, такие как системы торговли акциями.