ЖАНРЫ

Шрифт:

Если вы имеете доступ к IIS-серверу и можете его конфигурировать (в случаях, когда вы производите самостоятельный хостинг или хостинг на виртуальных серверах), вам необходимо самостоятельно зарегистрировать для IIS6 обработку расширения mvc. Это можно проделать двумя способами.

? Вы можете использовать скрипт register.wsf, который поставляется с ASP.NET MVC и расположен по адресу C:\Program Files\Microsoft ASP.NET\ASP.NET MVC\Scripts или C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC\Scripts для 64-битных операционных систем. Скрипт register.wsf автоматически зарегистрирует обработку расширения mvc для IIS6.

? Вместо использования скрипта вы можете проделать

необходимые для регистрации действия собственноручно. Для этого необходимо пройти в свойства проекта, выбрать вкладку Virtual Directory и в ней нажать кнопку Configuration. В окне конфигурации приложения будет показан список привязок расширений к ISAPI-обработчикам. Добавьте новое расширение mvc и привяжите его к обработчику c:\WINDOWS\Microsoft.NET \Framework\v2.0.50727\aspnet_isapi.dll. Путь к обработчику ISAPI может отличаться, но вы можете определить верный, найдя сопоставленный путь для расширения aspx. После добавления обработчика вы увидите его в списке сопоставлений (рис. П1.2).

Рис. П1.2. Список сопоставлений расширений и ISAPI-обработчиков

? После сопоставления расширения mvc для вашего приложения необходимо видоизменить создание маршрутов в Global.asax так, как показано в листинге П1.1.

Листинг П1.1. Модифицированный код Global.asax

using System;

using System.Collections.Generic;

using System.Linq; using System.Web;

using System.Web.Mvc;

using System.Web.Routing;

namespace MvcApplicationl {

public class MvcApplication : System.Web.HttpApplication

{

public static void RegisterRoutes(RouteCollection routes)

{

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(

"Default",

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

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

);

routes.MapRoute(

"Root",

"",

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

);

}

protected void Application_Start

{

RegisterRoutes(RouteTable.Routes);

}

}

}

Обратите внимание на выделенные участки кода листинга П1.1. Вместо создаваемого по умолчанию маршрута с шаблоном {controller}/{action}/{id}, для IIS6 необходимо создать маршрут с шаблоном {controller}.mvc/{action}/{id}. Плюс, для обработки запросов к корню приложения необходимо создать еще один маршрут с именем Root и пустым шаблоном маршрута.

После таких изменений каждый запрос к вашему приложению должен иметь вид {controller}.mvc/{action}/{id}, т. е. каждая строка имени контроллера должна заканчиваться с расширением mvc. Например: запрос /product.mvc/details/1 вызовет контроллер-действие Details в контроллере Product и передаст в параметр id значение 1.

В случае, когда вы не имеете доступа к конфигурированию сервера IIS и не можете задать сопоставление расширения и ISAPI-обработчика, то решением может стать использование вместо расширения mvc другого расширения, зарегистрированного в системе: axd, aspx, ashx. В таком случае описанный в листинге код должен быть модифицирован следующим образом:

routes.MapRoute(

"Default",

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

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

);

Это

означает, что все ваши запросы должны представлять собой подобие запроса /product.aspx/details/1 с расширением aspx для имени контроллера.

Ограничение IIS6 приводит к тому, что маршрутизация и строки URL-запросов к вашему приложению не будут выглядеть так же красиво, как в приложениях, работающих на базе IIS7. Кроме того, вам будет необходимо генерировать совместимые ссылки с определенными маршрутами и используемыми в них расширениями (mvc или aspx). Однако в настоящее время использование серверов IIS6 в компаниях, которые предлагают услуги хостинга, стремится к нулю, и все крупные хостеры уже предлагают хостинг на базе IIS7 или даже IIS7.5. Поэтому, перед тем как сделать выбор хостера, уточните, предлагает ли он сервер на базе IIS7, и если обнаружится, что он по какой-то причине до сих пор этого не делает, то, возможно, вам следует поискать другого, более современного хостера.

ПРИЛОЖЕНИЕ 2

Оптимизация производительности

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

Здесь мы дадим некоторые базовые советы по оптимизации как производительности приложений на сервере, так и на клиентской стороне в браузере пользователя.

Кэширование данных

Одним из базовых инструментов повышения производительности является кэширование сгенерированных данных, в основном, веб-страниц. В ASP.NET существует базовый инструмент кэширования данных с помощью директивы @outputcache, параметры которой позволяют управлять временем кэширования страницы и задавать условия, при которых кэширование происходит.

В ASP.NET MVC для кэширования результатов выполнения действий в контроллерах предлагается использовать специальный атрибут outputcacheAttribute, который представляет собой аналог директивы @outputcache. Например, далее представлен код, который позволяет кэшировать все результаты контроллера на 30 минут:

[OutputCache(Duration = 1800, VaryByParam = "none")]

public class AdminController : Controller

Подробнее параметры этого атрибута рассмотрены в главе 4.

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

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

Поделиться с друзьями: