СравненеиеSilverlightvsFlash.

В настоящее время самая успешная и популярная надстройка браузера — AdobeFlash — установлена в более чем 96% браузеров по всему миру. Технология Flash имеет долгую историю — более десяти лет. Изначально Flash была простым инструментом добавления анимированной графики, но со временем она постепенно превратилась в мощную платформу разработки интерактивного содержимого.

Для разработчиков.NET создание веб-сайтов с использованием содержимого Flash выглядит вполне естественным. Однако для Flash нужны отдельные инструменты разработки — совершенно другой язык программирования (ActionScript) и другая среда программирования (Flex).

Хуже всего то, что не существует простых способов интеграции содержимого Flash с серверным кодом.NET. В частности, для обращения объекта Flash к компоненту.NET потребуется приложить немалые усилия. Использование серверного кода.NET для вывода содержимого Flash (например, для создания элемента управления ASP.NET, который манипулирует содержимым Flash) — еще более тяжелая задача.

По сравнению с Flash, Silverlight существенно облегчает манипулирование содержимым.NET. Главная цель Silverlight — обеспечить создание приложений, столь же мощных и кроссплатформенных, как и Flash, на основе первоклассной платформы программирования.NET. Благодаря этому разработчики могут создавать клиентский код Silverlight на том же языке (C# или VB), что и серверный код. Кроме того, разработчики могут применять в клиентском коде Silverlight те же абстракции, что и в серверном коде, включая потоки ввода-вывода, элементы управления, коллекции, обобщенные объекты и средства LINQ.

 

 

Особенности работы с анимациями в SilverLight

Silverlight — это название новой технологии представления данных в Интернете, предназначенной для запуска на различных платформах. Она позволяет создавать насыщенные, визуально привлекательные веб-страницы, работающие в различных обозревателях, устройствах и настольных операционных системах (напримерAppleMacintosh). Ключом к возможностям Silverlight, как и ко всей технологии представления WPF (WindowsPresentationFoundation) платформы Microsoft.NET Framework 3.0, является XAML (e X tensible A pplication M arkup L anguage, расширяемый язык

разметки приложений).

 

Профили

Ранее вы ознакомились с широким диапазоном средств безопасности ASP.NET. Многие из этих средств связаны с идентификацией индивидуальных пользователей (аутентификацией) и последующим определением действий, которые им разрешено выполнять (авторизацией). Однако уникально идентифицировать и аутентифицировать пользователей важно еще и по другой причине, а именно - чтобы отслеживать специфическую для конкретного пользователя информацию.

В ASP.NET 1.x единственная практическая возможность сохранять специфичную для пользователя информацию состояла в создании собственных компонентов доступа к данным. Веб-страница может вызывать методы этого компонента доступа к данным, чтобы получать данные текущего пользователя и затем сохранять любые изменения в них. Этот подход по-прежнему имеет смысл во многих сценариях. Однако в ASP.NET 2.0 появилось другое средство, называемое профилями, которое в ASP.NET 4 осталось неизменным. Когда используются профили, ASP.NET автоматически управляет извлечением специфичных для пользователя данных, обращаясь за ними к источнику данных заднего плана (обычно - к базе данных).

Концептуально средство профилей очень похоже на создание собственных компонентов базы данных. Однако в нем имеется ряд удобств. Наиболее впечатляет то, что это средство интегрировано с моделью аутентификации ASP.NET так, что информация о пользователе автоматически извлекается для текущего пользователя, когда это необходимо, и (если эта информация изменяется) записывается в базу данных в конце текущего запроса. Важнее всего то, что код веб-страницы обращается к данным профиля текущего пользователя с применением строго типизированных свойств.

Одним из наиболее существенных отличий между профилями и другими типами управления состоянием является то, что профили предназначены для постоянного хранения информации с использованием источников данных заднего плана, таких как база данных. Большинство других типов управления состоянием предназначено для поддержки информации для последовательности запросов, поступающих за относительно короткое время (вроде непостоянных cookie-наборов и состояния представления), или для передачи информации от одной страницы к другой (такой как межстраничная отправка и строки запросов). Если нужно хранить информацию более длительное время в базе данных, то профили предоставляют для этого удобную модель, которая управляет хранением и извлечением информации.

Производительность профилей

Назначение средства профилей ASP.NET заключается в обеспечении прозрачного способа управления специфичной для пользователя информацией без необходимости писать специальный код доступа к данным с применением классов данных ADO.NET.

К сожалению, многие средства, которые выглядят удобными, страдают от недостаточной производительности или масштабируемости. Это, в частности, касается профилей, поскольку они предполагают доступ к данным, а обращение к базам данных может легко превратиться в узкое место любого распределенного приложения.

С точки зрения производительности профили лучше работают, когда удовлетворяются следующие условия:

1. Есть относительно немного страниц, которые обращаются к данным профиля.

2. Сохраняется небольшой объем данных.

Хуже они работают при таких условиях:

1. Есть много страниц, которые нуждаются в использовании информации профиля.

2. Сохраняются большие объемы данных. Особенно низкая эффективность будет, когда необходимо использовать лишь некоторые из запрошенных данных (поскольку модель профилей всегда извлекает блок данных профиля целиком).

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

Сравнение профилей и специальных компонентов данных

Профили - естественный конкурент специальных компонентов данных, вроде тех, которые строили в статье «Компонент доступа к данным». Ясно, что компоненты данных обладают большей гибкостью. Они позволяют не только поддерживать специфичную для пользователя информацию, но также сохраняют информацию и другого рода, а также позволяют решать сложные бизнес-задачи.

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

Стандартный поставщик профилей, входящий в ASP.NET - SqlProfileProvider, не предоставляет многих дополнительных средств помимо сохранения в базе данных и извлечения оттуда. В следующем списке перечислены некоторые средства, которые можно легко добавить через специальный компонент базы данных, но которые не доступны SqlProfileProvider. Если требуется любое из этих средств, следует отказаться от профилей и создать собственный компонент доступа к данным или же разработать собственный поставщик профилей:

Шифрование

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

Проверка достоверности

Вы не можете ограничить тип информации, которая помещается в профиль. Для предотвращения появления недопустимых данных необходимо использовать дополнительные инструменты Кэширование

Если информация профиля используется на странице, она всегда извлекается из базы данных. Информацию из профиля нельзя хранить в памяти. Хотя можно скопировать информацию профиля в кэш, это сильно затруднит ее отслеживание.

Диагностика

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