Текст книги "Asp.net mvc framework"

Автор книги: Гайдар Магдануров

сообщить о нарушении

Текущая страница: 12 (всего у книги 17 страниц)

}

Этот тест направлен на проверку определения маршрута при доступе к сайту по URL без каких-либо параметров или относительных путей. Здесь ожидается, что по умолчанию должен сработать маршрут Default и выполниться действие Index контроллера HomeController.

Для того чтобы запустить наш тест, необходимо скомпилировать проект с тестом и запустить среду NUnit, главное окно которой представлено на рис. 6.7.

C помощью пункта меню File | Open Project добавим в среду сборку нашего проекта тестирования. В моем случае это сборка Routing.dll. После того как сборка загрузится, нажмите кнопку Run для запуска тестов. Как можно убедиться, наш тест не пройден (рис. 6.8).

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

маршрутизации и создает маршруты, необходимые для последующего тестирования:

[TestFixtureSetUp]

public void SetUp()

{

  MvcApplication.RegisterRoutes(RouteTable.Routes);

}

[TestFixtureTearDown]

public void TearDown()

{

  RouteTable.Routes.Clear();

}

Обратите внимание на атрибуты TestFixtureSetUp и TestFixtureTearDown. Эти атрибуты необходимы для определения кода, который будет вызван перед тестом и сразу после него. В нашем случае перед тестами создаются маршруты, а после теста – разрушаются.

Скомпилируем проект и запустим тест еще раз. На этот раз тест пройден (рис. 6.9).

Для интереса вы можете теперь попробовать модифицировать маршрут Default так, чтобы наш тест перестал работать, например, можно переименовать название действия по умолчанию с Index на Index2. После этого тест будет провален.

Добавим тест для проверки маршрута под названием Product, в нем маршрут определяется простым шаблоном без участия имени действия:

[Test]

public void TestProduct()

{

  "~/Product/750".Route()

         .ShouldMapTo(x => x.GetById(750));

}

Добавим еще один тест, на этот раз для проверки игнорирования маршрута для AXD-запросов:

[Test]

public void TestIgnoreAxd()

{

  "~/someroutetoigonre.axd".ShouldBeIgnored();

}

Запустите тесты и убедитесь, что они пройдены. Обратите внимание на используемый метод расширения ShouldBeIgnored, который предназначен как раз для тестирования игнорирования маршрутов.

Последний наш тест будет направлен на проверку ограничений маршрута. Для тестирования маршрута ProductList определим два следующих теста:

[Test]

public void TestProductListValidYear()

{

"~/ProductList/2009".Route()

         .ShouldMapTo(x => x.List(2009));

}

[Test]

public void TestProductListInvalidYear()

{

           Assert.AreNotEqual("~/ProductList/1800".Route().Values["controller"],

                    "Product");

}

Первый тест TestProductListValidYear производит знакомые нам действия, при правильном значении параметра year, ограничение не должно действовать и маршрут должен быть сопоставлен контроллеру Product и действию List. Второй тест TestProductListInvalidYear, наоборот, проверяет поведение маршрута при неверном с точки зрения ограничения параметре year (он должен быть более или равен 1900). Для того чтобы протестировать этот момент, сравниваются имя сопоставленного контроллера и имя контроллера Product. Для успешного прохождения теста они не должны быть равны. Теперь, если убрать ограничение из маршрута, тест будет провален.

После написания всех тестов и запуска NUnit мы должны получить следующую картину успешного прохождения всех тестов (рис. 6.10).

В листинге 6.3 приведен код перечисленных ранее тестов для тех, кто использует тестирование на базе встроенного в Visual Studio инструмента MSTest. Различий минимум и все они касаются именования атрибутов, которое в NUnit отличается от MSTest.

Листинг 6.3. Тестирование с помощью MSTest

namespace Routing

{

  using System.Web.Routing;

  using Microsoft.VisualStudio.TestTools.UnitTesting;

  using MvcContrib.TestHelper; using Routing.Controllers;

  [TestClass]

  public class TestRoutesMSTest

  {

    [TestMethod]

    public void TestSimpleRoute()

    {

      "~/".Route().ShouldMapTo(x => x.Index());

    }

    [TestInitialize]

    public void SetUp()

    {

      MvcApplication.RegisterRoutes(RouteTable.Routes);

    }

    [TestCleanup]

    public void TearDown()

    {

      RouteTable.Routes.Clear();

    }

    [TestMethod]

    public void TestProduct()

    {

      "~/Product/750".Route()

           .ShouldMapTo(x => x.GetById(750));

    }

    [TestMethod]

    public void TestIgnoreAxd()

    {

      "~/someroutetoigonre.axd".ShouldBeIgnored();

    }

    [TestMethod]

    public void TestProductListValidYear()

    {

      "~/ProductList/2009".Route()

             .ShouldMapTo(x => x.List(2009));

    [TestMethod]

    public void TestProductListInvalidYear()

    {

      Assert.AreNotEqual("~/ProductList/1800".Route()

                  .Values["controller"], "Product");

    }

  }

}

Утилита ASP.NET Routing Debugger

Для тестирования и проверки правильности создания маршрутов в вашем приложении может пригодиться небольшой инструмент от разработчиков MVC Framework. Данный инструмент позволяет в режиме отладки проверить все зарегистрированные маршруты на работоспособность. Кроме того, этот инструмент поможет посмотреть на то, как и в каком порядке реагируют ваши маршруты на запросы с различными адресами URL.

Примечание

Инструмент ASP.NET Routing Debugger доступен для скачивания по адресу http://haacked.eom/archive/2008/03/13/u rl-routing-debugger.aspx.

*****************************

Для работы с Routing Debugger необходимо добавить в проект ссылку на сборку RouteDebug.dll и в файле Global.asax добавить одну строку кода в методе Application_Start так, как показано в следующем фрагменте:

protected void Application_Start()

{

  RegisterRoutes(RouteTable.Routes);

  RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);

}

После этого, запущенный проект вместо ожидаемой страницы выведет специальную страницу с отчетом о зарегистрированных в проекте маршрутах и их параметрах (рис. 6.11).

ASP.NET Routing Debugger может быть полезен, когда ваш проект содержит массу определенных маршрутов. В таком случае вы получаете наглядный инструмент, который покажет вам порядок и параметры маршрутов, и их реакцию на любой запрос. Используя Routing Debugger, вам не придется долго ломать голову над вопросом: "Почему на этот запрос вызывается этот маршрут?"

Заключение

Маршрутизация – это значительный элемент ASP.NET и базовый механизм для работы MVC Framework. Маршрутизация позволяет организовать обработку пользовательских запросов в виде, удобном для построения приложения, согласно паттерну MVC. С использованием маршрутизации в MVC Framework можно отойти от привязки запроса к конкретной странице ASPX и использовать строку запроса как описатель необходимого для вызова действия и контроллера.

С помощью механизмов маршрутизации можно управлять тем, как обрабатываются клиентские запросы, создавать ограничения на запросы или создать список запросов, которые вовсе будут игнорироваться. Таким образом, понимание работы маршрутизации – это важное требование при разработке приложения на базе MVC Framework.

В этой главе мы рассмотрели механизм маршрутизации ASP.NET, его значение и применение при разработке проектов с использованием MVC Framework. Нами были подробно описаны составные части маршрутизации, применяемые в ней классы, интерфейсы и коллекции. Мы показали, как создавать маршруты, использовать таблицы маршрутизации, ограничения маршрутов и игнорирования маршрутов. В завершение главы нами были даны советы по использованию механизма маршрутизации, в том числе по организации модульного тестирования созданных маршрутов.

ГЛАВА 7

Ajax-функциональность

 Последнее время все чаще и чаще слышны разговоры про Ajax. Появилось множество сайтов, использующих эту технологию, многие из них разработаны гигантами вроде Google или Microsoft. Ajax стал краеугольным механизмом для нового понятия Web 2.0. Так что же это такое – Ajax?

Ajax расшифровывается как Asynchronous JavaScript And XML, т. е. "асинхронный JavaScript и XML". Основное предназначение Ajax – осуществление запросов и получение данных для веб-страницы асинхронным способом, без перезагрузки самой страницы. Таким образом, пользователь не замечает запросы, посылаемые на сервер, а данные, передаваемые между сервером и клиентом, значительно уменьшаются в связи с тем, что пропадает надобность формировать и отправлять пользователю всю страницу целиком, по этой же причине снимается существенная нагрузка на сервер, которому нет нужды перестраивать страницу целиком или помещать ее в кэш.

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

История успеха Ajax

Технология Ajax начала свою жизнь в середине 90-х годов. Когда вебтехнологии стали развиваться бурными темпами, появилась конкуренция браузеров и многие крупные компании старались внести свой вклад в создание будущего вида интернет-технологий. Так, компания Microsoft представила в 1996 году элемент iFrame, который позволял в одном окне браузера загружать данные из нескольких источников. Одним из применений iFrame стала незаметная для пользователя загрузка данных в скрытый фрейм с последующим использованием этих данных на основной странице. Можно сказать, что IFrame заложил некоторые основы Ajax, и даже сегодня данный подход широко используется на практике.

Чуть позднее компания Microsoft вновь внедрила инновационную технологию в свой браузер Internet Explorer, которая позволяла еще более просто асинхронно получать данные с сервера. Эта технология сегодня известна как объект XMLHttpRequest, который поддерживается всеми браузерами. Изначально XMLHttpRequest представлял собой ActiveX-компонент, который могли использовать разработчики, создающие свои продукты, нацеленные на работу в Internet Explorer. Этот компонент позволял при помощи JavaScript делать асинхронные запросы на сервер с получением данных в формате XML. Сама компания Microsoft использовала его в веб-версии почтового клиента Outlook.

Появление предка XMLHttpRequest можно считать рождением эры Web 2.0, хотя в то время ни такого термина, ни самого наступления новой эры никто не заметил. Потребовалось еще несколько лет, чтобы о технологии заговорили, и был даже придуман специальный термин. Значительное влияние на популяризацию и распространение технологии Ajax оказала компания Google, которая выпустила инновационные и сверхпопулярные в наше время проекты Gmail и Google Maps. Оба продукта Google не предлагали ничего нового: Gmail – это почтовый клиент, а Google Maps – сервис онлайн-карт, подобные которому уже существовали на рынке. Однако изменился сам подход и опыт использования приложений пользователем. Теперь вместо обязательных частых перезагрузок страницы при навигации по письмам или картографическому сервису пользователь получал интерфейс, который напоминал ему обычную настольную программу. Не было перезагрузок страницы с долгим ожиданием, вместо этого данные пользователя незаметно подгружались с сервера Google с использованием Ajax (рис. 7.1).

Пользователи очень быстро заслуженно оценили сервисы Google за их удобство, скорость работы и высокую отзывчивость. Кроме того, компания предложила беспрецендентный объем бесплатного почтового ящика в несколько гигабайт, но это уже другая история. Успех Gmail и Google Maps не прошел незамеченным, и технологией асинхронной передачи данных между браузером клиента и сервером стали интересоваться многие разработчики. Интерес к новому подходу при построении веб-сайтов все возрастал, все больше появлялось ресурсов, которые позволяли управлять собой без перезагрузок страницы, предлагая пользователю новый и интересный опыт общения с Интернетом.

В 2005 году Джейси Джеймс Гарретт, специалист по разработке пользовательских интерфейсов, придумывает специальный термин к технологии, которая уже заразила Интернет. Этим названием стал известный нам термин Ajax. В своей статье «Ajax: A New Approach to Web Applications» Гарретт описал как саму технологию, так и дал ей название. Ознакомиться с довольно объемной и подробной статьей можно и сегодня по адресу http://www.adaptivepath.com/ideas/essays/archives/000385.php. 18 февраля 2005 года, день выхода статьи, можно считать днем рождения старой технологии под новым именем, которое изменило представление об Интернете.

В апреле 2006 года консорциум W3C утвердил первый черновик стандарта, который описывал объект XMLHttpRequest. Это стало заключительным аккордом в широком распространении технологии Ajax, теперь основополагающая технология была стандартизирована, и ничто не мешало ее дальнейшему распространению.

Современный Ajax

В наше время уже трудно найти новые веб-проекты, которые бы не использовали технологию Ajax. Да и многие другие старые и заслуженные ресурсы также получают обновление сервисов с включением Ajax в той или иной мере. Например, вслед за появлением Gmail другой популярный сервис Hotmail также обзавелся Ajax-интерфейсом, за ними последовали многие другие почтовые онлайн-сервисы.

Применение Ajax находится повсюду, например, крупнейший социальный сервис с IT-тематикой Habrahabr.ru использует Ajax для препросмотра написанной статьи или комментария, для изменения рейтинга записей и пользователей. Другие популярные социальные сервисы вроде Facebook или Spaces предпочитают использовать Ajax для простых действий наподобие подтверждения пользователем своих действий или работы с данными других пользователей сети.

Еще одним интересным применением Ajax, которое предлагает пользователю новый опыт при использовании интерфейсов веб-приложений, стало извлечение данных по требованию. Так, например, Google Reader, популярный сервис для чтения RSS-каналов, позволяет с помощью скроллирования получать все новые и новые данные RSS-ленты, хотя предзагружена изначально лишь малая их часть. Подобный вариант, только более наглядный для пользователя, использует поисковой сервис Bing, в котором реализован "бесконечный" поиск по изображениям. Новые результаты поиска в виде набора изображений будут подгружаться по мере того, как пользователь скроллирует страницу все ниже и ниже (рис. 7.2).

Помимо простого влияния Ajax на современное представление о пользовательских интерфейсах, технология Ajax оказывает огромное влияние на интернет-индустрию в целом. Ajax вдохнул вторую жизнь в веб-сайты, многие из которых стали дублировать функционал, который ранее казался привязанным к десктопу. Появились ресурсы, которые позволяют редактировать офисные документы или изображения. Движение Rich Internet Applications, которое, как ранее казалось, будет осуществляться посредством плагинов и сторонних технологий вроде Flash или Silverlight, теперь вполне осуществимо стандартными веб-технологиями на основе браузера, HTML и JavaScript. Конечно, RIA на базе веб-технологий пока отстает по производительности и возможностям от технологий Flash/Silverlight, но многие задачи, которые ранее решались с помощью Flash, теперь можно решить на базе усиленного с помощью Ajax HTML-интерфейса.

Широкое распространение Ajax не могло пройти мимо инструментов разработчиков, и почти все они обзавелись поддержкой Ajax, с помощью которой работа с Ajax-запросами значительно упрощается. Такие Framework, как ExtJS, jQuery, MooTools и другие популярные инструменты для разработки JavaScript-кода, конечно, имеют поддержку Ajax. Об одном из таких инструментов пойдет речь и в этой главе. jQuery – популярнейший JS Framework содержит несколько инструментов для удобной работы с Ajax и, что очень важно, включен в состав Visual Studio и проект MVC Framework по умолчанию.

Пример использования Ajax

Для того чтобы понять, что такое Ajax, достаточно рассмотреть один или несколько примеров его использования. Создадим реализацию классического примера, который использует механизм Ajax для получения текущего времени с сервера.

Первым делом мы должны создать экземпляр объекта XMLHttpRequest:

var xhr;

if (window.XMLHttpRequest)

{

  xhr = new XMLHttpRequest();

}

else

  if (window.ActiveXObject)

  {

    xhr = new ActiveXObj ect("Microsoft.XMLHTTP");

  }

  else

  {

    alert("Браузер не поддерживает XMLHttpRequest!");

  }

Здесь в переменной xhr создается объект XMLHttpRequest. В зависимости от типа браузера доступ к этому объекту может быть разным. Старые версии Internet Explorer работают только через создание ActiveX-компонента. В Internet Explorer 7 и выше работа с XMLHttpRequest приведена к стандарту.

Для обработки результатов асинхронного запроса XMLHttpRequest используется свойство onreadystatechange, которое вызывается всякий раз, как объект XMLHttpRequest изменяет свое состояние. Для проверки текущего состояния используется другое свойство readyState, которое содержит значение текущего состояния XMLHttpRequest. Все возможные значения readyState перечислены далее:

□ readyState = 0 – запрос не инициализирован;

□ readyState = 1 – запрос был установлен;

□ readyState = 2 – запрос был отправлен;

□ readyState = 3 – запрос происходит в данное время;

□ readyState = 4 – запрос завершен, получен результат.

Другое свойство responseText отвечает за хранение ответа от сервера после запроса. Если совместить использование всех этих свойств вместе, то можно написать следующий часто используемый код обработки асинхронного запроса:

xhr.onreadystatechange = function() {

  if (xhr.readyState == 4) {

    docum.ent.getElementById("timeText") .value = xhr.responseText;

  }

}

Здесь свойству onreadystatechange присваивается функция для обработки изменения состояния объекта XMLHttpRequest, представленного переменной xhr. Функция проверяет свойство readyState на значение 4, которое говорит об успешном завершении запроса и присваивает элементу с идентификатором timeText текстовое значение результата запроса.

Для создания запроса к серверу используется две функции XMLHttpRequest: open и send. Функция open содержит три параметра:

□ текстовое значение с типом запроса: GET или POST;

□ текстовое значение со строкой запроса, указывающей на страницу, к которой необходимо выполнить запрос;

□ булево значение, определяющее, должен ли быть запрос асинхронным.

Функция send содержит один параметр, который должен определять данные, отправляемые вместе с запросом. Данные могут представлять собой как некую строку, так и XML-документ. В настоящее время чаще всего используется первый вариант, когда данные передаются в виде строки JSON-данных.

Для того чтобы отправить запрос на сервер, нужно вызвать следующий код:

xhr.open(«GET»,"Home/GetTime",true);

xhr.send(null);

Запрос будет отправлен к ресурсу по относительному адресу Home/GetTime, когда сервер обработает запрос и пришлет ответ, в объекте xhr изменится состояние и будет вызвана наша реализация функции onreadystatechange.

Полный код примера, созданный на базе проекта MVC Framework по умолчанию, представлен в листинге 7.1.

Листинг 7.1

<%@ Page Language="C#"

       MasterPageFile="~/Views/Shared/Site.Master"

       Inherits="System.Web.Mvc.ViewPage" %>

           runat="server">

  Home Page

           runat="server">

 

    <%= Html.Encode(ViewData["Message"]) %>

 

 

    To learn more about ASP.NET MVC visit

      http://asp.net/mvc« title=»ASP.NET MVC Website">http://asp.net/mvc.

 

 

   

   

    Время не получено

 

В этом фрагменте кода создается кнопка для запроса данных с сервера, к которой привязан JavaScript-код Ajax и текстовое поле для отображения результата.

Серверный код, необходимый для работы, примитивен и представляет собой следующую реализацию действия GetTime для контроллера HomeController. Обратите внимание на использование атрибута OutputCache для предотвращения кэширования результата, которое в нашем случае не нужно:

[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]

public ActionResult GetTime()

{

  return Json(DateTime.Now.ToString());

}

Запустив проект, мы можем запрашивать дату и время с сервера без перезагрузки страницы и с использованием технологии Ajax (рис. 7.3).

Мы рассмотрели принцип работы Ajax на базе XMLHttpRequest на простейшем примере. В действительности все несколько сложнее. Следует учитывать возможные ошибки, которые могут возникнуть при обработке запроса, необходимо обрабатывать истечение времени ожидания ответа от сервера. Для упрощения работы с Ajax существуют специальные библиотеки и Framework, про которые речь пойдет далее.

MVC Framework и Ajax

MVC Framework, как новый и современный инструмент, конечно, поддерживает Ajax и предлагает удобные и обширные средства по работе с ним. На самом деле MVC Framework содержит два отдельных Ajax-инструмента: стандартную библиотеку с классами-помощниками и библиотеку jQuery, одной из возможностей которой является упрощенная работа с Ajax.

Ajax-функционал в MVC Framework

В состав проекта MVC Framework по умолчанию входят два JavaScript-файла: MicrosoftAjax.js и MicrosoftMvcAjax.js, в которых для разработчиков предложены вспомогательные функции при работе с Ajax. Рассмотрим их по порядку:

□ MicrosoftAjax.js – основной файл, который содержит всю инфраструктуру ASP.NET для работы с Ajax. Эта библиотека может быть знакома тем, кто использовал Ajax.NET или AjaxControlToolkit в проектах на базе классического ASP.NET;

□ MicrosoftMvcAjax.js – файл, осуществляющий поддержку Ajax в MVC-проектах, код которых написан с помощью специальных вспомогательных методов. Эта библиотека использует MicrosoftAjax.js для своей работы.

Для упрощения работы с Ajax MVC Framework содержит кроме JavaScript-файлов еще и расширения в виде классов и методов .NET. Так, класс viewPage, по умолчанию базовый для всех страниц MVC-проектов, содержит свойство Ajax, которое является экземпляром класса AjaxHelper.AjaxHelper содержит перечисленные в табл. 7.1 вспомогательные методы для работы с Ajax в представлениях.

Чтобы использовать данные расширения в своих проектах, необходимо подключить оба JavaScript-файла, MicrosoftAjax.js и MicrosoftMvcAjax.js, на необходимую страницу либо для всех страниц сразу через файл master-страницы. Код для добавления ссылок на эти файлы в master-странице может быть следующим:

Далее мы рассмотрим более подробно эти вспомогательные методы и еще один вспомогательный класс AjaxOptions и свойство IsAjaxRequest, также имеющие отношение к Ajax.

AjaxOptions

Класс AjaxOptions представляет собой набор свойств, которые описывают разнообразные опции Ajax-запросов для вспомогательных методов MVC Framework. AjaxOptions содержит следующие свойства:

□ Confirm – задает текст, который будет выведен в запросе пользователю перед осуществлением запроса. Установка этого параметра приведет к тому, что перед запросом на сервер у пользователя будет возможность подтвердить отправку запроса или отменить ее (рис. 7.4);

Рис. 7.4. Запрос подтверждения при использовании параметра Confirm

□ HttpMethod – устанавливает тип HTTP-запроса (GET или POST), который будет использоваться при формировании асинхронного запроса. Может содержать одно из двух значений Get или Post, по умолчанию установлено в Post;

□ InsertionMode – свойство задает одно из значений одноименного перечисления InsertionMode: Replace, InsertBefore, InsertAfter. Значение по умолчанию Replace. Данное свойство устанавливает метод включения данных из ответа от сервера в элемент разметки: перезапись значения элемента, добавление до содержимого или после него. Данное свойство используется совместно со свойством UpdateTargetId, указывающим идентификатор элемента разметки, в которое будет записано значение результата ответа от сервера;

□ LoadingElementId – задает идентификатор элемента разметки, который должен быть отображен во время Ajax-запроса. Использование данного свойства приведет к тому, что указанный элемент будет показан во время запроса, а затем скрыт. Использование этого свойства имеет смысл для демонстрации пользователю анимации ожидания во время продолжительных запросов;

□ OnBegin – задает наименование JavaScript-функции, которая должна быть вызвана непосредственно перед отправкой асинхронного запроса на сервер;

□ Oncomplete – задает наименование JavaScript-функции, которая должна быть вызвана сразу после того, как запрос был завершен, и до того, как результат запроса был записан в элемент разметки. Не имеет значения, был ли завершен запрос удачно или нет, функция, указанная через Oncomplete, все равно будет вызвана. Данная функция будет вызвана до onFailure или onSuccess. Если требуется, чтобы результат не был записан в элемент разметки, то функция, указанная в Oncomplete, должна вернуть false;

□ OnFailure – задает наименование JavaScript-функции, которая должна быть вызвана в случае, когда асинхронный запрос завершился с ошибкой;

□ OnSuccess – задает наименование JavaScript-функции, которая должна быть вызвана в случае, когда асинхронный запрос завершился успешно;

□ updateTargetid – задает идентификатор элемента разметки, в который должен быть записан результат асинхронного запроса на сервер. Вместе с этим параметром может быть использован параметр InsertionMode, который указывает, каким именно способом должны быть записаны данные в элемент разметки;

□ url – устанавливает значение адреса сервера, куда следует отправить запрос. Свойство использовать не обязательно, когда класс AjaxOptions применяется в Ajax.BeginForm и Ajax.ActionLink, где действие и контроллер задают данные адреса. В случае если Url все же будет указан, он переопределит значения, определенные в этих методах.

Класс AjaxOptions и его свойства используются во вспомогательных методах Ajax.BeginForm и Ajax.ActionLink для тонкой настройки асинхронного запроса и его параметров, а также действий, осуществляемых в ответ на изменение состояния запроса. Например, в следующием фрагменте кода AjaxOptions используется для задания ряда параметров при вызове Ajax.ActionLink:

 

  <%= Ajax.ActionLink(«получить время», «GetTime», «Home»,

    new AjaxOptions() {

      OnFailure="OnError",

      Confirm="Bы уверены?",

      UpdateTargetId = "timeText"

    },

    (object) null)

  %>

  Нажмите на ссылку для получения времени<^span>

Ajax.BeginForm

Вспомогательный метод Ajax.BeginForm, в зависимости от реализации, содержит набор из следующих параметров:

□ actionName – указывает наименование действия, которое следует вызвать в запросе, в случае, когда используется вариант метода без указания контроллера, вызывается действие контроллера текущего контекста;

□ controllerName – указывает наименование контроллера (сокращенное, без суффикса Controller), в котором следует искать и вызвать указанное в параметре actionName действие;

□ routeValues – указывает объект, содержащий параметры для механизма маршрутизации;

□ ajaxOptions – указывает экземпляр класса AjaxOptions с заданными свойствами, которые определяют параметры асинхронного запроса и могут определять ряд JavaScript-функций, реагирующих на изменение состояния запроса;

□ htmlAttributes – набор значений пользовательских атрибутов для тега form, которые должны быть помещены в разметку формы.

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

<% using(Aj ax.BeginForm(«LoginForm»,

     new AjaxOptions{UpdateTargetId="loginStatus"})) {

%>

 

    Введите логин и пароль, чтобы продолжить.

 

 

Введите логин:

 

<%= Html.TextBox("login")%>

 

Введите пароль:

 

<%= Html.TextBox("password")%>

 

<% } %>

Здесь с помощью вспомогательного метода Ajax.BeginForm создается стандартная форма авторизации с двумя текстовыми полями для ввода логина и пароля и кнопкой отправки данных. Обратите внимание на параметры Ajax.BeginForm: во-первых, указывается LoginForm – наименование действия, которое должно вызваться в ответ на отправку данных с формы, во-вторых, с помощью класса AjaxOptions задается специальный параметр UpdateTargetId, который указывает на элемент, ответственный за отображение результата запроса. То есть, если запрос вернет данные, они будут отображены, в нашем случае, с помощью элемента span с идентификатором loginStatus.

Как можно заметить, создание всего Ajax-функционала не потребовало у нас ни строчки JavaScript, не требуется от нас и понимание различий реализаций поддержки Ajax разными браузерами. Все это скрытно реализуют библиотеки MicrosoftAjax.js и MicrosoftMvcAjax.js, делая за разработчика всю рутинную работу по организации работы с асинхронными запросами. Если мы взглянем на исходный код, который сгенерирует подсистема Ajax в MVC Framework для нашего кода, то сможем убедиться, что генерируется достаточно много автоматического кода. Далее представлено определение формы, которое создано автоматически для нашего примера: