ASP.NET 4.5 и Unobtrusive Validation, Progressive Degradation и что это все нам дает.

В ASP.NET 4.5 среди прочих нововведений, во всю начал применяться так называемый подход Unobtrusive JavaScript, то есть, "ненавязчивый JavaScript" и использование jQuery. Эта технология уже применяется в ASP.NET MVC, по-моему, с третьей версии, и вот, теперь дело дошло и до WebForms.

Что же это за зверь "Unobtrusive JavaScript"? Это относительно новый подход к разработке клиентской части web-страниц, предполагающий несколько вещей:

1. Отделение поведения (JavaScript) от структуры и представления (HTML/CSS). То есть, такой своеобразный вариант клиентского MVC.
2. Попытки избежать традиционных проблем JavaScript (т.е., максимально возвожная браузеро- и платформонезависимость и масштабируемость)
3. Использование подхода Graceful degradation, то есть приложение должно оставаться работоспособным при использовании даже старых браузеров возможно вообще не поддерживающих JavaScript.

В ASP.NET все эти принципы проявляются в виде Unobtrusive Validation, о которой я постараюсь вам рассказать применительно к общей концепции Unobtrusive JavaScript.

В качестве примера давайте создадим простой web-приложение на ASP.NET 4.5 и добавим в него одну единственную страничку с текстовым полем, кнопкой и валидатором того, что текстовое поле заполнено. 

Как вы, наверное, помните, в предыдущих версиях добавление валидатора влекло за собой добавление в код страницы целой простыни JavaScript кода. А что сейчас? Давайте попробуем запустить наш пример.

И вот, мы сразу же натыкаемся на то, чем нам этот переход на использование UnobtrusiveValidation по умолчанию грозит.

Я уже упоминал вначале, что теперь для валидации (и, кстати, для серверных вызовов, например, при использовании UpdatePanel тоже) используется jQuery. Так что нам нужно либо отключить UnobtrusiveValidation, либо добавить jQuery. Давайте вначале расскажу, как вернуться к старой модели, а потом продолжим рассказ про "светлое будущее". 

Отключить новую модель валидации проще простого. Для этого достаточно добавить в web.config параметр ValidationSettings:UnobtrusiveValidationMode:

В результате, все заработает и будет как раньше - с простыней JavaScript, который, к тому же, не будет работать на старых браузерах.
Напомню как это выглядит (сама разметка в "кадр" не поместилась - только JavaScript)

А теперь давайте попробуем запустить наше приложение с использованием новой модели. Как вы, наверное, уже догадались просто добавить ссылку на jQuery в HTML разметке будет явно недостаточно. Теперь предполагается, что все скрипты, используемые на странице,  будут добавляться с помощью ScriptManager. Для этого надо добавить в проект файл Global.asax и в событие Application_Start добавить вот такой код:

 
        protected void Application_Start(object sender, EventArgs e)
        {
            ScriptManager.ScriptResourceMapping.AddDefinition("jquery",
            new ScriptResourceDefinition
            {
                Path = "~/scripts/jquery-1.8.3.min.js",
                DebugPath = "~/scripts/jquery-1.8.3.js",
                CdnPath = "http://ajax.microsoft.com/ajax/jQuery/jquery-1.8.3.min.js",
                CdnDebugPath = "http://ajax.microsoft.com/ajax/jQuery/jquery-1.8.3.js",
                CdnSupportsSecureConnection = true,
                LoadSuccessExpression = "window.jQuery"                
            });
        }

Вот мы и подошли к тому, что было отменно в самом начале статьи под пунктом 1 - разделения кода и HTML.
Как видно из этого кода, теперь существуют две версии скрипта - для отладки и для релиза, которые, кстати, подставляются автоматически в зависимости от того под какой конфигурацией вы собираете проект. И, каждый из файлов теперь можно загружать не только из локальной директории, а и с отдельного сервера. Если теперь запустить наш проект и посмотреть на HTML то мы увидим, что JavaScript в теле самой страницы уже нет, зато появились атрибуты data-val-*, которые используются плагином jQuery Validation с помощью которого теперь производится валидация.

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

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

Давайте пробуем разобраться что такое Progressive Degradation.
Основной смысл в том, что приложение должно оставаться работоспособным даже в случае использование устаревших или мобильных браузеров. Может пострадать "красота", возможно не будет каких-то модных возможностей типа постепенной подгрузки контента с помощью AJAX, но приложение будет работать. И, естественно, не должно быть никаких ошибок, связанных с невозможностью использования "продвинутых" возможностей.
Попробуйте, отключите в браузере JavaScript, или замените в коде номера версий jQury на что-то типа 9999.9999. Запустите приложение, нажмите на кнопку. Все работает, корректно, появляется сообщение о необходимости заполнения текстового поля. Единственное отличие от "полноценной" версии в том, что сейчас проверка была проведена не с помощью jQuery, а на сервере - если присмотреться, то заметен postback. По-моему, отличная иллюстрация принципа Graceful Degradation.

Касательно Unotrusive JavaScript вы можете еще столкнуться с термином Progressive Enhancement. Это то же самое, что Graceful Degaradation, но наоборот. То есть, при использовании Progressive Enhancement разработка ведется снизу-вверх, от базовой версии в более "навернутой". Базовый функционал, работающий корректно всегда и всевозможные "плюшки и украшательства" (например, показ видео с помощью HTML5) появляющиеся в зависимости от доступности средств их использованию.

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