В процессе разработки ПО, когда ещё не весь функционал определён окончательно, структура БД часто изменяется. И если используется какой-либо ORM-framework, изменение БД после изменения модели данных доставляет некоторые неудобства (по сути нужно проделать двойную работу по изменению класса модели и структуры БД). Вкратце, как сделать миграцию в EF4 Code First с помощью Package Manager Console описано здесь, я же постараюсь описать как работает автоматическая миграция без участия разработчика (точнее, при минимальном участии).

Всё мы знаем, что в ASP.NET MVC есть такой атрибут HandleErrorAttribute, который как сказано в MSDN

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

Но нигде, в том же MSDN не сказано (ткните меня носом дайте ссылку где это написано, если я просмотрел), что он обрабатывает только исключения, устанавливающие код ответа сервера в 500.

Посмотрев на исходный код HandleErrorAttribute легко убедиться в этом. Там имеются следующие строки:

// If this is not an HTTP 500 (for example, if somebody throws an HTTP 404 from an action method),
// ignore it.
if (new HttpException(null, exception).GetHttpCode() != 500) {
    return;
}

Не знаю, как вам, а мне удобнее при возникновении исключения, чтобы пользователи видели специальную страницу для этого, а не «жёлтую страницу смерти» или вообще как браузер отображает стандартную для него страницу с кодом ответа сервера (зависит от настроек в Web.config, но об этом позже).

В ASP.NET MVC есть встроенная возможность ограничить доступ к тем или иным контроллерам и их действиям. Эта возможность предоставляется атрибутом AuthorizeAttribute, но возможностей и гибкости ему явно не хватает (точнее их практически нет). Права можно определить только на этапе разработки и без повторной компиляции никак не изменить. А ведь создать собственный атрибут, обладающий необходимым функционалом совсем не сложно.