Гайдар Магдануров - ASP.NET MVC Framework

При работе с контроллерами в MVC Framework полезной практикой является механизм наследования контроллеров. Так как контроллеры представляют собой классы, преимущества наследования контроллеров схожи с преимуществами наследования классов в C#. Основным таким преимуществом является возможность создания базового набора правил для некоторого количества контроллеров. Для этого в MVC Framework можно определить контроллер, который будет называться базовым, и наследовать все остальные контроллеры от него.

Далее перечислены примеры возможных функций базовых контроллеров:

□ хранение и предоставление информации о текущем пользователе и его правах;

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

□ экземпляры хранилищ кода для работы с разнообразным функционалом: от пользователей до специфических данных приложения;

□ вспомогательные статические или другие методы утилитарного характера;

□ определение набора атрибутов, которые будут наследовать потомки базового контроллера.

Рассмотрим простейший пример базового контроллера. Для этого определим для него набор функционала: обработку ошибок, GZip-сжатие результатов действий, вспомогательную функцию для работы с пользователем и загрузчик некоторых параметров из файла web.config.

Листинг 4.7. Базовый контроллер

[HandleError(View = "AdminError")]

[GZipCompress]

public class BaseController : Controller

{

public NameValueCollection Settings

{

get

{

return ConfigurationManager.AppSettings;

}

}

public string UserNotFoundMessage

{

get

{

return Settings["userNotFoundMessage"];

}

}

public readonly MembershipProvider MP = Membership.Provider;

public virtual ActionResult Index()

{

return View();

}

public static MembershipUser GetUser(string userName)

{

MembershipProvider mp = Membership.Provider;

return mp.GetUser(userName, false);

}

public static MembershipUser GetUser(Guid userId)

{

MembershipProvider mp = Membership.Provider;

return mp.GetUser(userId, false);

}

}

Базовый контроллер из листинга 4.7 обладает следующими свойствами:

□ определяет для контроллера действие по умолчанию Index;

□ определяет атрибуты по умолчанию для обработки ошибок и сжатия результатов через GZip;

□ определяет обертку Settingsнад секцией настроек appSettingsфайла web.config, для более прозрачного доступа к настройкам;

□ прямо определяет UserNotFoundMessage, одну из настроек секции appSettingsдля быстрого к ней доступа;

□ определяет упрощенный доступ к объекту Membership.Provider;

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

Чтобы наделить этими свойствами любой контроллер, необходимо наследовать его от базового. Модифицируем контроллер AdminControllerсогласно новым правилам так, как показано во фрагменте:

public class AdminController : BaseController {

[AcceptVerbs(HttpVerbs.Get)]

[Authorize(Users = "Admin")]

public override ActionResult Index()

{

int userCount;

var users = MP.GetAllUsers(0, Int32.MaxValue, out userCount);

ViewData.Model = users;

return View();

}

[AcceptVerbs(HttpVerbs.Get)]

[Authorize(Users = "Admin")]

public ActionResult Select(Guid? userId)

{

if (!userId.HasValue)

throw new HttpException(404, UserNotFoundMessage);

return View("Select", "Site", GetUser(userId.Value));

}

}

Обратите внимание, класс контроллера наследует BaseController, в связи с этим действие Indexпереопределяется с помощью ключевого слова override. Кроме того, в Indexиспользуется новое свойство mp, определенное в базовом контроллере. В другом действии, Select, используются два других функционала базового контроллера: свойство UserNotFoundMessageи статический метод GetUser.

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

При создании веб-приложений часто может возникнуть проблема с обработкой данных, которая отнимает большие ресурсы и машинное время. Механизм ASP.NET имеет ограниченное количество потоков, которые предназначены для обработки пользовательских запросов, полученных от сервера IIS. Проблема состоит в том, что если один из запросов предполагает продолжительную работу с привлечением больших ресурсов, то такой запрос может уменьшить пропускную способность сайта. В случаях, когда таких запросов много, их выполнение может вообще заблокировать доступ пользователей к ресурсу, т. к. все рабочие потоки ASP.NET будут заняты, простаивая в ожидании того, когда завершится выполнение тяжелого запроса к базе данных или сложное вычисление.

Выходом из такой ситуации может служить асинхронное выполнение запросов. При асинхронном выполнении тяжелая задача поручается для выполнения отдельному специально созданному потоку, а основной поток ASP.NET освобождается для обработки других пользовательских запросов. Для реализации такого функционала разработчиками MVC Framework был создан специальный механизм AsyncController, который хоть и не вошел в MVC Framework, но доступен в особой библиотеке MVC Framework Futures, которая представлена файлом Microsoft.Web.Mvc.dll.

Саму библиотеку и документацию к ней на английском языке можно скачать с официальной страницы ASP.NET MVC на сайте Codeplex по следующему адресу: http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=24471

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

routes.MapAsyncRoute(

"Default",

"{controller}/{action}/{id}",

new { controller = "Home", action = "Index", id = "" }

);

Обратите внимание на то, что вызов routes.MapRouteзаменен на routes.MapAsyncRoute, это необходимо, чтобы механизм MVC мог обрабатывать как асинхронные, так и синхронные контроллеры. После изменений в регистрации маршрутов нет нужды в других изменениях, чтобы специально отслеживать синхронные контроллеры, поскольку механизм MapAsyncRouteрегистрирует маршруты как для асинхронных, так и синхронных контроллеров.

После изменения регистрации маршрутов следует изменить обработчики для *.mvc, определенные ранее в web.config, следующим образом в разделах httpHandlersи handlers: