Я до сих пор не совсем понимаю, зачем мне нужно создавать настраиваемые фильтры действий. Может быть, пара примеров поможет.
Есть ли в вашем проекте фильтры действий, которые вы считаете обязательными? Может быть, даже настолько важно, что вы повторно используете их во всех своих проектах MVC?
Я использую фильтр действий «Ведение журнала» для регистрации всех вызовов моих контроллеров с дампом параметров — это может быть очень полезно во время стороннего тестирования, позволяя мне видеть, как/почему/когда люди взаимодействуют с приложением.
Хотя это и не фильтр действий, я также размещаю в своих репозиториях ловушку для регистрации, которая выводит SQL-код, сгенерированный любым кодом Linq2SQL... опять же полезно, чтобы точно видеть, что и когда выполняется.
Мой любимый «обязательный» фильтр, который я использую, — это тот, который проверяет модель представления, чтобы увидеть, есть ли какие-либо пустые списки. Если они есть, он пытается заполнить их из базы данных. В основном я использую это для заполнения общих раскрывающихся списков, поэтому мне не нужно помещать этот код в действие контроллера.
Неподдерживаемый фильтр браузера (UBF) — проверяет Request.Browser и перенаправляет на страницу загрузки браузера или облегченную страницу.
По умолчанию все наши контроллеры поддерживают только те браузеры, которые поддерживает jQuery. Но программист ван помечает контроллер специальным атрибутом для переопределения UBF.
Новые глобальные фильтры MVC3 делают использование UBF еще проще.
Любой общедоступный веб-сайт, безусловно, нуждается в какой-либо проверке человеком. Так почему бы не использовать тот, который очень силен и имеет очень хорошую цель. рекаптча.
Интеграция с MVC довольно легко.
Это повседневный сценарий создания уникальных записей в БД. Предположим, у вас есть сущность User. У вас установлены все возможные атрибуты проверки, но есть один, который вы не можете установить. И это то, уникален ли экземпляр сущности.
Зачем он вообще нам нужен?
Это два наиболее распространенных процесса с User сущностью, в которых задействована проверка:
Итак, затем вы создаете нового пользователя, вам, скорее всего, нужно проверить, является ли он уникальным в вашей БД (либо имя пользователя, либо адрес электронной почты, либо что-то подобное; что-то должно быть проверено на уникальность).
Но при обновлении не нужно проверять уникальность, потому что пользователь уже существует в БД.
Используя фильтр действий для действия Create. Но поскольку этот тип фильтра должен использоваться для всех типов сущностей, было бы разумно сделать его более универсальным и многоразовым, чтобы мы могли фактически использовать его для всех видов сущностей.
У меня есть два, без которых я не могу жить:
a) AjaxMasterPageInjectorAttribute : работа этого маленького парня состоит в том, чтобы проверить, является ли запрос IsAjax(), а затем переключиться на AjaxMasterPage без chrome, если это необходимо. Короларри — это JsonCommandInterceptor — он принимает ответ и изменяет его на команду Json для сценариев ajax по мере необходимости. Позволяет создать единую цепочку действий, которая динамически становится ajaxy, если вам это нужно.
б) ViewModelWrapperInjectorAttribute : захватывает модель представления и вставляет ее в какой-либо более глобальный ViewModelWrapper для всего сайта. Сосредоточьте ваши действия на том, что они должны делать, и отвлекайтесь от бизнеса по заполнению/предоставлению указанного ViewModelWrapper в более инфраструктурное место.
