Создание бизнес-приложений с помощью Silverlight
ОГЛАВЛЕНИЕ
Моя основная цель в данной статье заключается в том, чтобы взять бизнес-сценарий и построить приложение с нуля, иллюстрируя по дороге различные аспекты разработки Silverlight. Решение, о котором я буду говорить, – приложение центра обработки звонков, его логическая структура показана на рис. 1. В этой части я сконцентрируюсь на всплывающих на экране уведомлениях, асинхронной модели программирования, диалоговых оках Silverlight и реализации сервера междоменной политики TCP. В части 2 я поговорю о безопасности приложений, интеграции веб-служб, секционировании приложения и ряде других аспектов приложения.
Рис. 1. Логическая архитектура центра обработки звонков Silverlight
Основы Silverlight: CoreCLR
Прежде чем я приступлю, давайте обновим в памяти основы Silverlight. Сперва я загляну внутрь среды выполнения Silverlight, чтобы читателям было понятнее, что возможно с помощью Silverlight. CoreCLR – это виртуальный компьютер, используемый Silverlight. Он подобен CLR, на основе которой работают .NET Framework 2.0 и последующие версии, содержа похожие системы загрузки типов и сбора мусора.
CoreCLR имеет очень простую модель управления доступом для кода (CAS) – более простую чем в настольном CLR, поскольку Silverlight необходимо обеспечивать выполнение политик безопасности лишь на уровне приложения. Это обусловлено тем, что, как независимый от платформ веб-клиент, он не может полагаться на существование любых определенных политик предприятия или компьютера и не может позволять пользователю менять существующие политики. Есть несколько исключений, таких как OpenFileDialog и IsolatedStorage (изменение квоты хранения), где Silverlight необходимо прямое согласие пользователя на нарушение набора правил «песочницы» по умолчанию. OpenFileDialog используется для доступа к файловой системе, тогда как IsolatedStorage используется для доступа к изолированному от одноименных хранилищу и увеличения квоты хранения.
Для настольных приложений каждое исполняемое загружает ровно одну копию CLR и процесс ОС будет содержать лишь одно приложение. У каждого приложения имеется системный домен, общий домен, домен по умолчанию и ряд прямо созданных AppDomain (см. «JIT и гони: углубитесь во внутренние механизма .NET Framework, чтобы увидеть, как CLR создает объекты среды выполнения»). Похожая модель домена имеется в CoreCLR. В случае Silverlight несколько приложений, возможно, из разных доменов, будут выполнять один и тот же процесс ОС.
В Internet Explorer 8.0 каждая вкладка работает в собственном изолированном процессе; таким образом, все приложения Silverlight, размещенные внутри одной вкладки, будут работать в контексте экземпляра CoreCLR, как проиллюстрировано на рис. 2. Поскольку каждое приложение может происходить из различного домена, по соображениям безопасности, каждое приложение будет загружено в собственный AppDomain. Будет существовать столько же экземпляров CoreCLR, сколько существует вкладок, размещающих, на данный момент, приложения Silverlight.
Каждый AppDomain получит собственный пул статических переменных, как в настольной CLR. Каждый пул конкретного домена будет инициализирован в ходе процесса начальной загрузки AppDomain.
Рис. 2. Каждое приложение Silverlight запустит собственный AppDomain
Приложения Silverlight не могут создавать свои собственные, индивидуализированные домены приложений; эта способность зарезервирована для внутреннего использования. Более подробное описание CoreCLR можно найти в следующих статьях рубрики «CLR вдоль и поперек», написанных группой разработчиков CLR: "Программирование для Silverlight с помощью CoreCLR" и "Безопасность в Silverlight 2."