ASP_NET_MVC_4_Framework_s_primerami_na_C_dlya_p
.pdf
Выполнение валидации на стороне клиента
Техники валидации, которые мы продемонстрировали до сих пор, являются примерами валидации на стороне сервера. Это означает, что пользователь передает данные на сервер, сервер проверяет данные и отправляет обратно результат валидации (обработав данные, если валидация успешна, или отобразив список ошибок, которые должны быть исправлены).
В веб-приложениях пользователи обычно ожидают получить немедленную обратную связь перед тем, как они отправят данные на сервер. Это известно как валидация на стороне клиента и, как правило, реализуется с помощью JavaScript. Введенные данные проверяются перед отправкой на сервер, что обеспечивает пользователю немедленную обратную связь и возможность исправить все проблемы.
MVC Framework поддерживает ненавязчивую валидацию на стороне клиента (unobtrusive client-side validation). Термин «ненавязчивый» означает, что правила валидации выражаются с помощью атрибутов, добавленных к элементам HTML, которые мы создаем. Эти атрибуты интерпретируются библиотекой JavaScript, которая включена в MVC Framework; он, в свою очередь, использует библиотеку jQuery Validation, которая и выполняет всю работу по валидации. В следующих разделах мы покажем вам, как работает встроенная поддержка валидации и продемонстрируем способы расширения функциональности и создания пользовательской валидации на стороне клиента.
Подсказка
Валидация на стороне клиента ориентирована на проверку индивидуальных свойств. На самом деле, трудно создать валидацию уровня модели на стороне клиента с помощью встроенной поддержки MVC Framework. В связи с этим большинство приложений MVC используют валидацию на стороне клиента для уровня свойств и валидацию на стороне сервера для всей модели.
601
Активируем и дезактивируем валидацию на стороне клиента
Валидация на стороне клиента контролируется двумя настройками в файле Web.config, как показано в листинге 23-19.
Листинг 23-19: Управляем валидацией на стороне клиента
<appSettings>
<add key="ClientValidationEnabled" value="true"/> <add key="UnobtrusiveJavaScriptEnabled" value="true"/>
</appSettings>
Чтобы валидация на стороне клиента работала, оба эти параметра должны содержать значение true. При создании проекта MVC Visual Studio устанавливает для них значение true.
Подсказка
Можно также настроить валидацию на стороне клиента для отдельных представлений, указав
HtmlHelper.ClientValidationEnabled и HtmlHelper.UnobtrusiveJavaScriptEnabled в блоке кода
Razor.
Для работы валидации на стороне клиента также необходимо, чтобы в коде HTML, отправленном в браузер, были ссылки на три библиотеки JavaScript:
/Scripts/jQuery-1.7.1.min.js
/Scripts/jQuery.validate.min.js
/Scripts/jQuery.validate.unobtrusive.min.js
Самый простой способ добавить эти JavaScript файлы в представление – с помощью связок скриптов (script bundles). Это новая функция в MVC 4, которую мы опишем в главе 24. Здесь мы не будем объяснять принципы ее работы, но добавим с ее помощью необходимые нам скрипты в файл /Views/Shared/_Layout.cshtml; изменения показаны в листинге 23-20. (То же изменение можно было бы сделать в представлении MakeBooking, но мы предпочитаем импортировать скрипты в макеты, чтобы не приходилось вносить изменения во все представления).
Листинг 23-20: Добавляем в макет библиотеки JavaScript, необходимые для валидации на стороне клиента
<!DOCTYPE html> <html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width" /> <title>@ViewBag.Title</title> @Styles.Render("~/Content/css") @Scripts.Render("~/bundles/modernizr")
</head>
<body>
@RenderBody()
@Scripts.Render("~/bundles/jquery")
@Scripts.Render("~/bundles/jqueryval")
@RenderSection("scripts", required: false) </body>
</html>
602
Используем валидацию на стороне клиента
Теперь, когда мы активировали валидацию на стороне клиента и убедились, что в макете есть ссылки на библиотеки JavaScript, можно выполнять валидацию на стороне клиента. Для этого проще всего применить атрибуты метаданных, которые мы использовали ранее для валидации на стороне сервера, такие как Required, Range и StringLength. В листинге 23-21 показан класс модели Appointment с этими атрибутами (мы удалили реализацию интерфейса IValidatableObject, который совершенно не влияет на валидацию на стороне клиента).
Листинг 23-21: Атрибуты валидации, примененные к объеку модели Appointment
using System;
using System.ComponentModel.DataAnnotations;
namespace ModelValidation.Models
{
public class Appointment
{
[Required]
[StringLength(10, MinimumLength = 3)] public string ClientName { get; set; }
[DataType(DataType.Date)]
public DateTime Date { get; set; }
public bool TermsAccepted { get; set; }
}
}
Это все, что необходимо для базовой настройки валидации на стороне клиента. Мы применили несколько встроенных атрибутов валидации, чтобы продемонстрировать функции валидации на стороне клиента; если отправленный клиенту код HTML ссылается на библиотеки JavaScript, то все заработает.
Чтобы увидеть эффект от валидации на стороне клиента, запустите приложение, перейдите по ссылке /Home/MakeBooking и введите букву X в поле имени. Нажмите клавишу tab или кликните по другому элементу ввода, и вы сразу увидите сообщение валидации, созданное JavaScript, как показано на рисунке 23-11.
Рисунок 23-11: Немедленная обратная связь при использовании валидации на стороне клиента
603
В листинге 23-21 мы применили к классу Appointment атрибут валидации StringLength, и на рисунке вы увидите сообщение об ошибке от этого атрибута. Браузер обеспечивает немедленную обратную связь, не отправляя запросов к серверу. На самом деле, выполняющий валидацию код JavaScript будет препятствовать отправке формы до тех пор, пока все явные ошибки валидации не будут исправлены.
Исправляя ошибку, пользователь также получает немедленную обратную связь. Если вы вернетесь к полю Name и продолжите ввод, ошибка валидации исчезнет, когда в имени будет три и более символа. Но если вы продолжите печатать и дойдете до одиннадцатого символа, сообщение об ошибке появится снова. Это произойдет потому, что в атрибуте StringLength для свойства ClientName мы указали минимальную длину строки из трех букв, а максимальную – из десяти.
Принципы работы валидации на стороне клиента
Одним из преимуществ использования валидации на стороне клиента в MVC Framework является то, что нам не придется писать JavaScript. Правила валидации создаются с помощью HTML-атрибутов. Когда валидация на стороне клиента отключена, вспомогательный метод Html.EditorFor создаст для свойства ClientName следующий код HTML:
<input class="text-box single-line" id="ClientName" name="ClientName" type="text" value="" />
А вот HTML, который будет создан для того же свойства при активированной валидации на стороне клиента:
<input class="text-box single-line" data-val="true"
data-val-length="The field ClientName must be a string with a minimum length of 3 and a maximum length of 10."
data-val-length-max="10" data-val-length-min="3" data-val-required="The ClientName field is required." id="ClientName" name="ClientName" type="text" value="" />
Поддержка валидации на стороне клиента в MVC не генерирует никакого JavaScript или данных JSON, которые бы управляли процессом валидации; как это часто бывает в работе с MVC Framework, здесь мы полагаемся на соглашения. Первым был добавлен атрибут data-val. С помощью этого атрибута библиотека jQuery Validation определяет те поля, для которых требуется валидация.
Индивидуальные правила валидации задаются с помощью атрибута в форме data-val-<name>, где name – это правило. Так, например, для атрибута Required, который мы применили к классу модели, был в HTML создан атрибут data-val-required. Значение в атрибуте - это сообщение об ошибке, связанное с правилом. Для некоторых правил требуются дополнительные атрибуты, как, например,
для правила length, для которого атрибуты data-val-length-min и data-val-length-max
позволяют задавать минимальную и максимальную длину строки.
Правила валидации required и length интерпретируются библиотекой JQuery Validation, на которой построены все функции валидации на стороне клиента MVC. Одна из приятных особенностей валидации на стороне клиента MVC заключается в том, что для создания правил валидации на стороне клиента и на сервере применяются одни и те же атрибуты. Это означает, что данные из браузеров, которые не поддерживают JavaScript, подлежат той же проверке, как и данные из браузеров, поддерживающих JavaScript, и это не требует от нас каких-либо дополнительных усилий.
604
Валидация на стороне клиента MVC и валидация jQuery
Функции валидации на стороне клиента MVC построены на библиотеке JQuery Validation. Если хотите, можете использовать библиотеку Validation напрямую, не обращая внимания на функции MVC. Библиотека Validation очень гибкая и функционально богатая; ее полезно изучать, чтобы научиться настраивать функции MVC и наилучшим образом использовать имеющиеся варианты валидации. Адам подробно описывает библиотеку JQuery Validation в книге Pro jQuery (Apress, 2012).
Выполнение удаленной валидации
Последняя функция валидации, которую мы рассмотрим в этой главе, - это удаленная валидация. Это техника валидации на стороне клиента, которая для выполнения валидации вызывает метод действия на сервере.
Распространенный пример удаленной валидации - это проверка доступности имени пользователя в приложениях, где такие имена должны быть уникальными; пользователь отправляет данные, и выполняется валидация на стороне клиента. Как часть этого процесса на сервер отправляется запрос Ajax, с помощью которого проводится валидация указанного имени пользователя. Если имя занято, то отображается ошибка валидации, чтобы пользователь мог ввести другое значение.
Это похоже на обычную валидацию на стороне сервера, но у этого подхода есть некоторые преимущества. Во-первых, удаленная валидация проводится только для отдельных свойств; преимущества валидации на стороне клиента все еще сохраняются для всех других значений данных. Во-вторых, запрос относительно легкий и ориентирован на валидацию, а не обработку всего объекта модели. Это означает, что мы можем сократить затраты производительности, которые требуются для этого запроса.
Третье отличие состоит в том, что удаленная валидация выполняется в фоновом режиме. Пользователь не должен нажимать на кнопку Submit и дожидаться визуализации нового представления. Это влияет на удобство работы с приложением, особенно в случае медленного соединения.
Таким образом, удаленная валидация является компромиссом; она позволяет нам найти баланс между клиентской валидацией и валидацией на стороне сервера. Хотя она не требует запросов к серверу, но и выполняется не так быстро, как обычная валидация на стороне клиента.
Чтобы использовать удаленную валидацию, для начала необходимо создать метод действия, который будет проверять одно из свойств модели. Мы будем проводить валидацию для свойства Date модели Appointment, чтобы гарантировать то, что указанная встреча состоится в будущем (это одно из первых правил валидации, которое мы использовали в начале главы, но его невозможно реализовать с помощью стандартных функций валидации на стороне клиента). В листинге 23-22 показан метод действия ValidateDate, который мы добавили в контроллер Home.
Листинг 23-22: Добавляем метод валидации в контроллер Home
using System;
using System.Web.Mvc;
using ModelValidation.Models;
namespace ModelValidation.Controllers
{
public class HomeController : Controller
{
605
public ViewResult MakeBooking()
{
return View(new Appointment {Date = DateTime.Now});
}
[HttpPost]
public ViewResult MakeBooking(Appointment appt)
{
if (ModelState.IsValid)
{
//statements to store new Appointment in a
//repository would go here in a real project return View("Completed", appt);
}
else
{
return View();
}
}
public JsonResult ValidateDate(string Date)
{
DateTime parsedDate;
if (!DateTime.TryParse(Date, out parsedDate))
{
return Json("Please enter a valid date (mm/dd/yyyy)", JsonRequestBehavior.AllowGet);
}
else if (DateTime.Now > parsedDate)
{
return Json("Please enter a date in the future", JsonRequestBehavior.AllowGet);
}
else
{
return Json(true, JsonRequestBehavior.AllowGet);
}
}
}
}
Методы действий, которые поддерживают удаленную валидацию, должны возвращать тип JsonResult, который сообщает MVC Framework, что мы работаем с данными JSON. Кроме результата, метод валидации должен определить параметр с тем же именем, что и проверяемое поле данных. В этом примере это Date. Мы проверяем, возможно ли создать объект DateTime из значения, которое предоставил пользователь, и, если да, проверяем, что дата состоится в будущем.
Подсказка
Мы могли бы использовать связывание данных и сделать параметром нашего метода действия объект DateTime, но в таком случае метод валидации не будет вызван, если пользователь введет что-то совершенно бессмысленное, например apple. Так произойдет потому, что механизм связывания не сможет создать объект DateTime из значения apple и сгенерирует исключение. Функция удаленной валидации не имеет
возможности отобразить это исключение, и поэтому оно будет незаметно удалено. В результате поле ввода не будет подсвечено, что создаст впечатление, что введенное пользователем значение является действительным. Лучше всего при работе с удаленной валидацией принять строковый параметр в методе действия и выполнить преобразование, анализ или связывание данных явно.
606
Мы выражаем результаты валидации с помощью метода Json, который создает результат в формате JSON; этот результат будет проанализирован и обработан скриптом удаленной валидации на стороне клиента. Если обработанное значение отвечает нашим требованиям, то мы передаем true в метод Json в качестве параметра:
return Json(true, JsonRequestBehavior.AllowGet);
Если мы недовольны значением, то в качестве параметра передаем сообщение об ошибке валидации, которое должно быть показано пользователю, например:
return Json("Please enter a date in the future", JsonRequestBehavior.AllowGet);
В обоих случаях мы передаем в качестве параметра значение JsonRequestBehavior.AllowGet, потому что MVC Framework по умолчанию запрещает запросы GET, которые создают JSON, и это поведение необходимо переопределить. Без этого дополнительного параметра запросы валидация будет незаметно опускаться, и ошибки валидации не будет отображаться клиенту.
Чтобы использовать метод удаленной валидации в классе модели, мы применяем атрибут Remote к свойству, которое хотим проверить. В листинге 23-23 показано, как мы применили его к свойству
Date.
Листинг 23-23: Используем атрибут Remote в классе модели
using System;
using System.ComponentModel.DataAnnotations; using System.Web.Mvc;
namespace ModelValidation.Models
{
public class Appointment
{
[Required]
[StringLength(10, MinimumLength = 3)] public string ClientName { get; set; }
[DataType(DataType.Date)]
[Remote("ValidateDate", "Home")] public DateTime Date { get; set; }
public bool TermsAccepted { get; set; }
}
}
Аргументами для этого атрибута являются имя действия и контроллера для создания ссылки, с помощью которой библиотека валидации JavaScript будет выполнять валидацию; в нашем случае, это действие ValidateDate в контроллере Home.
Чтобы увидеть, как работает удаленная валидация, запустите приложение, перейдите по ссылке /Home/MakeBooking и введите дату, которая произошла в прошлом. Во время ввода появится сообщение валидации, как показано на рисунке 23-12.
607
Рисунок 23-12: Выполнение удаленной валидации
Внимание!
Метод валидации будет вызван, когда пользователь отправит форму в первый раз, а затем каждый раз, когда он будет редактировать данные. В сущности, каждое нажатие клавиши будет отправлять вызов к серверу. В некоторых приложениях может получиться значительное число запросов, и это следует принимать во внимание, когда вы будете определять мощность и пропускную способность сервера, которая потребуется для данного приложения. Кроме того, вы можете не использовать удаленную валидацию для свойств, если для нее потребуется слишком много ресурсов (например, если вам придется отправлять запросы к медленному серверу, чтобы определить, является ли имя пользователя уникальным).
Резюме
В этой главе мы рассмотрели широкий спектр техник, с помощью которых можно выполнять валидацию модели и гарантировать, что предоставленные пользователем данные согласуются с ограничениями, определенными моделью данных. Валидация моделей – это очень важная тема, и правильная настройка валидации для приложений необходима, чтобы обеспечить пользователям удобство работы без сбоев. Не менее важным является то, что мы обеспечиваем целостность доменной модели и не сохраняем в системе нерелевантные или проблематичные данные.
608
существуют альтернативы. Несмотря на то, что мы так любим те, которые Microsoft включила в новые проекты MVC, мы уверены, что если вам не понравится одна из библиотек в таблице, вы сможете найти ей замену, которая вас удовлетворит.
В дополнение к популярным библиотекам, которые показаны в таблице 24-1, папка Scripts содержит дополнительные библиотеки, которые поддерживают функции, специфические для Visual Studio или MVC. Они описаны в таблице 24-2.
Таблица 24-2: Специфические библиотеки для Visual Studio и MVC в папке Scripts
Имя файла |
Описание |
|
|
|
|
jQuery-1.7.1.intellisense.js |
С ее помощью Visual Studio завершает имена функций во время |
|
записа кода jQuery в файлах представлений. |
||
|
||
|
|
|
jQuery.unobtrusive-ajax.js |
С ее помощью MVC Framework поддерживает функцию |
|
ненавязчивого Ajax, которая была описана в главе 21. Построена |
||
|
на jQuery. |
|
|
|
|
|
С ее помощью Visual Studio завершает имена функций во время |
|
jQuery.validate-vsdoc.js |
записа кода jQuery, который использует библиотеку jQuery |
|
|
Validation. |
С ее помощью MVC Framework поддерживает функцию jQuery.validate.unobtrusive.js ненавязчивой валидации, которую мы описали в главе 23.
Построена на библиотеке jQuery Validation.
С файлами скриптов, которые поддерживают завершение кода в Visual Studio, не нужно делать ничего особенного. Когда они указаны в проекте приложения, Visual Studio находит и использует их автоматически. Ненавязчивый Ajax и библиотека валидации были описаны в главах 21 и 23. Эти скрипты как бы служат мостом между MVC Framework и функциональностью jQuery, на которой они построены.
В папке Scripts для многих из файлов, описанных в таблицах 24-1 и 24-2, есть две версии - обычная и минимизированная. Обычная версия содержит код JavaScript с комментариями, пробелами и значимыми именами функций и переменных. Они прекрасно подходят для отладки, так как вы можете прочитать исходный код и найти источник проблемы (одно из преимуществ JavaScript состоит в том, что его исходный код легко читается, потому что файлы JavaScript не компилируются до тех пор, пока не будут доставлены в браузер).
Проблема обычных файлов JavaScript в том, что они большие. Все полезные комментарии и значимые имена переменных и функций занимают место в файле, а следовательно, загрузка кода JavaScript займет больше времени и больше пропускной способности сервера.
Минимизированные файлы содержат ту же функциональность, что и соответствующие обычные файлы, но все читаемые имена, комментарии и пробелы были из них удалены, чтобы уменьшить размер файла. Чтобы вы лучше понимали эффект, отметим, что обычная библиотека jQuery, которую Visual Studio добавляет в новый проект, весит 252KB, уменьшенная версия - 92КБ. Вы можете удивиться, почему кого-то-то будет волновать разница в 160Кб, но если вы обслуживаете миллионов запросов в день, разница станет очевидна – как в количестве времени, которое пользователь будет ждать загрузки кода JavaScript, так и в пропускной способности, которая потребуется для серверов.
610