Partager via


«Домашнее задание» по клиентским технологиям (ASP.NET)

Ответы на вопросы «домашнего задания» с нашего семинара, посвященного клиентским технологиям — для начала по теме ASP.NET.

Пример реализации асинхронного обработчика HTTP ( IHTTPAsyncHandler) совместно с маршрутизацией URL-адресов ( URL routing)

Стив Сандерсон в своем блоге разбирает решение близкой задачи — «Improve scalability in ASP.NET MVC using Asynchronous requests». Несмотря на то, что пример кода был написан для ранней редакции ASP.NET MVC и требует корректировки, комментарии хорошо объясняют идею реализации, а также сценарий применения данного решения.

Кроме того, Microsoft MVP Джефри Чжао недавно опубликовал статью «Extend ASP.NET MVC for Asynchronous Action» с детальным анализом практического применения данного подхода.

Кстати, буквально на днях вышла новая редакция ASP.NET MVC Release Candidate. Как пишет Скотт Гатри, финальный релиз ожидается в течение ближайшего месяца.

К сожалению, базовый класс AsyncController не войдет в финальный релиз ASP.NET MVC версии 1, тем не менее, пока поставляется в сборке проекта ASP.NET MVC Futures. Это набор экспериментальных классов, которые планируются к выпуску в составе будущих версий ASP.NET MVC (читайте подробнее о разделении библиотеки MVC начиная с Beta 1 на официальную часть и «futures»).

Наконец, в библиотеке Machine, над которой работают Аарон Дженсен с коллегами, можно посмотреть свою реализацию AsyncController (/Source/Extensions/Machine.MsMvc).

Для чего может использоваться свойство TempData класса Controller?

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

По замыслу разработчиков ASP.NET MVC данное свойство может служить временным контейнером каких-либо данных при перенаправлении (redirect) запроса на другой контроллер. Например, со страницы обработки введенных пользователем данных, в случае, если обнаружена ошибка, обратно на страницу ввода данных. Пример — в статье Криса Тавареса из MSDN Magazine «Создание веб-приложений без форм».

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

Можно ли с помощью технологии ASP. NET Dynamic Data реализовать условно-ролевой доступ к определенным колонкам данных?

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

Да, это возможно, пример можно посмотреть в релизе проекта ASP.NET Dynamic Data Samples — см. пример «Secure Dynamic Data» в файле SecureDynamicData.zip.

ГБ