§ FluentFilters для ASP.NET MVC 3

Январь 31st, 2011
 | ASP.NET MVC

FluentFilter and ASP.NET MVC 3В прошлом году я писал о библиотеке FluentsFlters, посредством которой можно реализовать функциональность глобальных фильтров в ASP.NET MVC 2 приложении. С выходом ASP.NET MVC 3, командой разработчиков ASP.NET MVC была добавлена поддержка глобальных фильтров. Единственное чего не хватало, так это возможности определить условия для выполнения фильтра при регистрации.

Вооружившись Visual Studio 2010 я принялся переписывать библиотеку FluentFilters для интеграции с ASP.NET MVC 3, в последствии было выкошено много кода и переписано в соответствии с новой инфраструктурой работы с фильтрами в ASP.NET MVC 3, что позволяет начать использовать библиотеку при минимальных изменениях приложения. Ниже я опишу как нужно сконфигурировать приложение для работы с библиотекой и то как использовать критерии для регистрируемых фильтров. Также документацию можно найти на странице проекта на сайте CodePlex (на англ).
Читать больше »

, , ,
|
1 комментарий »

§ Обработка ошибок для всего сайта в ASP.NET MVC 3

Январь 23rd, 2011
 | ASP.NET MVC

Этим постом я расскажу, как можно отлавливать все исключения приложения и выводить для них различные страницы ошибок, например отображать представление ~/Views/Shared/Error.cshtml, которое используется для отображения необработанных в контроллерах исключений атрибутом HandleErrorAttribute.

Зачем?

Как я уже написал, HandleErrorAttribute обрабатывает только необработанные исключения контроллеров. Таким образом, если исключение произошло где-то в другом месте, то пользователь увидит страницу ошибки, сгенерированную сервером или страницу ошибки, указанную в разделе  customErrors файла Web.config. Также атрибут обрабатывает HTTP исключения только с кодом 500.

Для обработки несуществующих действий можно воспользоваться методом HandleUnknownAction класса Controller , который можно переопределить и написать логику для отображения страницы ошибки. Но этот метод не будет работать в том случае, если запрашиваемый URL не обрабатывается каким либо контроллером, т.е. ошибка 404 сгенерируется сервером и метод HandleUnknownAction не будет вызван и в таком случае пользователь увидит стандартную ошибку сервера или опять же указанную в разделе customErrors файла Web.config.

Все эти механизмы работают хорошо для некоторого круга задач, но иногда требуется иметь полный контроль над ошибками и выводить определённую страницу в зависимости от произошедшей ситуации.
Читать больше »

,
|
23 комментариев »

§ Fluent Filters – глобальные фильтры действий для ASP.NET MVC 2

Октябрь 28th, 2010
 | ASP.NET MVC

ASP.NET MVC 2Как-то в одном проекте, который писался на ASP.NET MVC 2, понадобилось реализовать средство для регистрации фильтров для всех контролеров в приложении, т.к. указывать атрибуты для каждого класса контроллера не совсем удобно если нужно выполнять одно и то же действие глобально, да и гибкости как таковой нет. Немного посёрфив я нашёл упоминание об этом только в roadmap для ASP.NET MVC 3.

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

  1. Простота регистрации фильтра в приложении
  2. Возможность добавления критериев для фильтров
  3. Возможность использования внедрение зависимостей (англ. Dependency injection) для фильтров

Механизм получился интересным и многофункциональным что я решил вынести это всё в отдельную библиотеку и поделиться с другими своими наработками. В конечном итоге и родилась библиотека Fluent Filters.
Читать больше »

, ,
|
2 комментариев »

§ URL в нижнем регистре в ASP.NET MVC 2

Октябрь 11th, 2010
 | ASP.NET MVC

ASP.NET MVC 2

В ASP.NET MVC ссылки генерируются по предопределённым маршрутам. Когда механизм маршрутизации ASP.NET MVC генерирует ссылку, то обычно мы можем видеть сгенерированную ссылку вида http://www.example.com/Home/About/. Как видно, то путевые части ссылки начинаются с заглавной буквы :? . Причина в том, что в шаблоне маршрута содержаться параметры, которые отображаются на имена контроллеров или действий, которые в свою очередь записаны в стиле Pascal casing. А этот стиль принят по умолчанию в соглашении об именовании для методов, классов, перечислений и пространств имен, ну и в свою очередь используется разработчиками при написании кода, а механизм маршрутизации по средствам рефлексии извлекает имена и вставляет их так, как они записаны в коде.

Например есть маршрут следующего вида:

1
2
3
4
5
6

routes.MapRoute(
    "Default", // Route name
    "{controller}/{action}/{id}", // URL with parameters
    new { controller = "Home", action = "Index", id = UrlParameter.Optional }, // Parameter defaults
    new[] { "MyMvcApplication.Controllers" } // Namespaces
);

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

Иногда было бы хорошо что бы все ссылки были только в нижнем регистре, независимо от того в каком регистре переданы или указаны имена параметров.
Читать больше »

,
|
2 комментариев »