Серверная валидация содержит несложные алгоритмы проверки проверяющие простейшие сценарии

Аннотация: Эта лекция содержит информацию о сценариях валидации данных и способах их реализации в рамках механизмов, доступных в составе ASP.NET.

Что такое валидация данных

Валидация – это процесс проверки данных на соответствие различным критериям. При разработке любого приложения в большинстве случаев разработчику приходится иметь дело с обработкой данных, которые ввел пользователь в соответствующие поля на форме. По разным причинам пользователь может вводить некорректные данные. Например, в поле «Возраст» он по ошибке может указать отрицательное или вовсе нечисловое значение. На практике встречается множество ситуаций, где определенные поля в пользовательском интерфейсе могут содержать только те данные, которые строго соответствуют определенным шаблонам. Если не учитывать подобные ситуации, то в процессе работы приложения могут возникать сбои, связанные с некорректным вводом пользователя. Ошибки могут быть допущены случайно или намеренно. В последнем случае пользователь может вводить некорректные данные с целью вывести приложение из строя и таким образом произвести атаку на приложение.
Поэтому каждое приложение, которое работает с данными, которые вводит пользователь (а таких приложений большинство) должно производить предварительную проверку корректности введенных данных. Именно по этой причине каждый разработчик должен быть знаком с механизмом валидации данных, которые указал пользователь.

Исторически, механизмы валидации данных разрабатывались самими разработчиками прикладных приложений. Это означает, что при каждой обработке запроса логике обработки запроса предшествовало большое количество условных операторов, определяющих условия корректности данных. Примером такого подхода может являться следующий фрагмент кода.

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

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

Существует два вида валидации данных, введенных пользователем.

клиентская валидация;
серверная валидация.

Клиентская валидация производится в бразуере на стороне клиента. Как правило, логика валидации на стороне клиента реализуется посредством сценариев JavaScript, которые запускаются внутри браузера. Клиентская валидация обычно содержит несложные алгоритмы проверки. Это происходит в силу того, что клиентский код физически не может обратиться к серверным ресурсам (например, к базе данных). Поэтому на стороне клиента проверяются самые тривиальные сценарии (такие как проверка длины строки, проверка на вхождение в диапазон и т.д.).

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

Серверная валидация работает в рамках программного кода, размещенного на стороне сервера. Здесь проверяются всевозможные случаи, в том числе те, которые уже были проверены на стороне клиента. Кроме тривиальных проверок, на стороне сервера могут работать более сложные алгоритмы. Необходимость дублирования проверки сценариев, которые уже были проверены на стороне клиента, обусловлена тем, что клиентские проверки могут не сработать, если в браузере у клиента отключено исполнение сценариев JavaScript. Другими словами наличие клиентской валидации не может гарантировать успешную проверку определенных там ограничений.

Общий алгоритм валидации данных, введенных пользователем можно представить следующим образом.

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

Краткие итоги

Большинство приложений так или иначе обрабатывает данные, которые вводит пользователь на странице. Пользователь может случайно или намеренно вводить некорректные данные. Поэтому требуется проверка пользовательского ввода при обработке запроса. Процесс проверки данных, введенных пользователем называется валидацией. Существует два типа валидации – серверная и клиентская. Серверная валидация производит всевозможные проверки и является основным механизмом валидации. Клиентская валидация позволяет обрабатывать алгоритмы валидации более интерактивно (на стороне клиента) и таким образом делает использование веб-приложения более удобным.

Источник

Валидацией будем называть проверку документа на соответствие веб-стандартами выявление существующих ошибок. Соответственно, валидным является такойвеб-документ,который прошел подобную процедуру и не имеет замечаний по коду. Кодвеб-страницыдолжен подчиняться определенным правилам, которые называются спецификацией, ее разрабатывает W3 Консорциум (www.w3c.org) при поддержке разработчиков браузеров.

На первый взгляд, кажется, что валидация необходима, ведь речь идет о сокращении количества ляпов разработчиков и написании «правильного» кода. На деле все обстоит гораздо сложнее и вокруг валидации до сих пор ведутся горячие споры об ее актуальности. Чтобы объективно раскрыть этот вопрос далее рассмотрим плюсы и минусы такой проверки.

Плюсы валидации

Хотя HTML-кодимеет достаточно простую иерархическую структуру, при разрастании объема документа в коде легко запутаться, следовательно, просто и совершить ошибку.

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

веб-страницу.

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

по-своему.

А это в свою очередь приводит к тому, что один и тот же документ может выглядеть

по-разному

в популярных браузерах. Исправление явных промахов и систематизация кода приводит, как правило, к стабильному результату.

Тенденции

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

Не стоит забывать и об XML (eXtensible Markup Language, расширяемый язык разметки). Этот язык становится стандартом де-фактодля хранения данных и обмена информацией между разными приложениями. Синтаксис XML более жесткий, чем HTML и не прощает малейших ошибок. Вкаком-тосмысле XML похож на языки программирования, в которых программа не будет скомпилирована, пока код не отлажен. HTML является первой ступенькой к изучению XML, поэтому приучая себя писать код по всем правилам, будет легче перейти к следующему этапу развития HTML.

Мода на валидацию

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

Косвенные преимущества

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

Минусы валидации

Сайты, конечно же, делают для того, чтобы их посещали люди. Именно посетители выступают мерилом работы сайта, а их интересует информация и способ ее получения. Пользователь желает, чтобы сайт корректно отображался в его любимом браузере, быстро загружался и содержал те материалы, которые ему нужны. Заметьте, в этом списке нет ничего про код документа и его валидность, посетителей это просто не интересует. Поэтому совершенно невалидный сайт, но выполненный с душой, наполненный интересными материалами привлечет к себе больше посетителей, чем пустой ресурс, но сделанный по всем «правилам».

Браузеры

Разработчики браузеров не всегда следуют спецификации и в некоторых случаях трактуют код не по заданным правилам, а по-своему.В конечном итоге это приводит к тому, чтовеб-страница,которая правильно (т.е. так, как и задумывали разработчики) отображается в одном браузере, выводится с ошибками в другом. Следование спецификации в подобных случаях, скорее всего, отпугнет пользователей некоторых браузеров. К примеру, Internet Explorer (IE) в настоящее время занимает лидирующее положение среди браузеров, но при этом поддерживает спецификацию HTML и CSS хуже, чем Firefox и Opera. Очевидно, что пользователи IE при посещении сайта выполненного по всем стандартам, но не учитывающего специфику этого браузера, увидят неприглядную картину.

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

Получается неутешительная картина — тратить время на отладку кода для соответствия спецификации нет особой нужды. Это время лучше посвятить тому, чтобы документ без проблем работал в разных браузерах — так в основном размышляют веб-разработчики.

Резюме

Так стоит ли проводить валидацию документов и заниматься этим этапом при написании веб-страниц?Безусловно, да.Кому-тоона поможет выявить существующие недочеты, другому поможет писать корректный код. Исправлять же ошибки, добиваясь полного соответствия стандартам, или оставить их ради совместимости с разными браузерами — здесь уже каждый решает сам, какие цели он преследует и что для него важнее.

studfiles.net

В заметке «Можно ли делить на 0,01 ?» на сайте тестировщиков я написал, что при тестировании нужно проверять согласованность валидаторов входных данных с логикой обработки этих данных приложением. Но из комментариев к этой заметке я понял, что для понимания того, как надо тестировать валидацию данных, надо понимать, как она должна работать, что можно считать правильным, а что нет. Поэтому я написал об этом отдельную статью. В ней рассматривается три вопроса: 1) зачем вообще нужна валидация данных, и 2) где и когда может выполняться валидация данных, 3) какие бывают разновидности проверок. Ну и конечно продемонстрировано, как всё это выглядит на живых примерах. А может быть мои рассуждения окажутся интересны не только тестировщикам, но и разработчикам.

Зачем нужна валидация данных?

Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.

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

Невозможность восстановиться после сбоя. Не всегда программа способна «вернуть всё назад». Возможно, в процессе работы программа выполнила какие-то необратимые действия — удалила файл, отправила данные по сети, напечатала что-то на принтер, запустила резец станка и он частично произвёл обработку заготовки детали. Но даже если восстановление в принципе возможно, алгоритм восстановления может тоже содержать ошибки, и это иногда приводит к совсем печальным последствиям.
Дополнительная нагрузка на систему. Восстановление после сбоя — это лишняя работа. Вся работа, которая была выполнена до момента сбоя — тоже лишняя. А это означает дополнительную нагрузку на систему, которой можно избежать, если заранее проверить данные. С другой стороны, валидация — это тоже дополнительная нагрузка, причём восстановление приходится делать лишь изредка, а проверку надо выполнять каждый раз, так что ещё неизвестно, что выгоднее.

Инъекции не вызывают сбоев. Один из основных способов эксплуатации уязвимостей в программах заключается в том, чтобы «обмануть» валидаторы, то есть передать данные, которые валидатор признаёт корректными, но при этом они интерпретируются непредусмотренным образом, так что злоумышленник может получить несанкционированный доступ к данным или некоторым возможностям программы, либо способен разрушить данные или программу. Если валидации нет вообще, задача злоумышленника максимально упрощается.
Сложность идентификации причины проблемы. Если исключение вылетело откуда-то из глубины программы, определить причины его возникновения не так-то просто. И даже если это возможно, может оказаться нелегко объяснить пользователю, что сбой вызван данными, которые он ввёл некоторое время назад в каком-то совершенно другом месте программы. А если проверка выполнена немедленно после ввода данных, никаких сложностей с идентификацией источника проблемы не возникает.

Короче говоря, отсутствие валидации может приводить к вышеописанным (а может быть и ещё каким-то другим) проблемам. Соответственно, наличие валидации позволяет предотвратить серьёзные сбои, упрощает идентификацию проблем, но за это приходится расплачиваться производительностью, поскольку дополнительные проверки увеличивают нагрузку на систему. И тут мы переходим ко второму вопросу — как уменьшить эту дополнительную нагрузку.

Где и когда выполнять валидацию данных?

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

Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.

Увы, здравый смысл иногда вынужден отступить перед натиском действительности. «Фейс-контроль» данных на входе иногда не просто нецелесообразен, но вообще невозможен. Ниже приведены некоторые причины этого.

Для валидации требуется доступ к недоступной части состояния системы. Это особенно характерно для проверки данных, вводимых человеком через графический интерфейс пользователя. Современные приложения часто построены с использованием многоуровневой архитектуры, которая предполагает, что реализация пользовательского интерфейса выделена в презентационный слой, а для проверки требуется доступ к другим слоям, вплоть до слоя базы данных.
Особенно хорошо это заметно для веб-приложений, где пользовательский интерфейс реализуется в браузере и выполняется на стороне клиента, а для проверки ввода требуется сравнение с тем, что хранится в базе данных. В этой ситуации проверку приходится выполнять уже после отправки данных на сервер. (Впрочем, сейчас с появлением AJAX-технологии эта проблема частично решена).
Валидация требует полностью повторить логику обработки. Как уже отмечено двумя абзацами выше, при многослойной архитектуре приложения пользовательский интерфейс обычно выделяется в специальный презентационный слой, а логика обработки данных находится на другом слое. И бывают такие ситуации, когда для валидации нужно практически полностью выполнить эту обработку, потому не существует более короткого способа понять, завершится она успехом или нет.

Как выполнять валидацию данных?

Впрочем, где бы ни выполнялась валидация, можно это делать несколькими различными способами, в зависимости от того, какие ограничения накладываются на данные.

Посимвольная проверка. Как правило такие проверки выполняются в пользовательском интерфейсе, по мере ввода данных. Но не только. Например, лексический анализатор компилятора тоже выявляет недопустимые символы непосредственно в процессе чтения компилируемого файла. Поэтому такие проверки можно условно назвать «лексическими».

Проверка отдельных значений. Для пользовательского интерфейса это проверка значения в отдельном поле, причём выполняться она может как по мере ввода (проверяется то неполное значение, которое введено к настоящему моменту), так и после завершения ввода, когда поле теряет фокус. Для программного интерфейса (API) это проверка одного из параметров, переданных в вызываемую процедуру. Для данных, получаемых из файла, это проверка какого-то прочитанного фрагмента файла. Такие проверки, опять-таки по аналогии с компиляторной терминологией, можно назвать «синтаксическими».
Совокупность входных значений. Можно предположить, что в программу сначала передаются какие-то данные, после чего подаётся некоторый сигнал, который инициирует их обработку. Например, пользователь ввёл данные в форму или в несколько форм (в так называемом «визарде») и наконец нажал кнопку «OK». В этот момент можно выполнить так называемые «семантические» проверки, нацеленные на валидацию не только отдельных значений, но и взаимосвязей между ними, взаимных ограничений.
Вполне возможна ситуация, когда каждое отдельное значение «синтаксически» корректно, но вместе они образуют несогласованный набор. Для программного интерфейса эта разновидность валидации предполагает проверку набора входных параметров вызываемой процедуры, для случая получения данных из файла это проверка всех прочитанных данных.
Проверка состояния системы после обработки данных. Наконец, есть последний способ, к которому можно прибегнуть, если валидацию непосредственно входных данных выполнить не удаётся — можно попытаться их обработать, но оставить возможность вернуть всё к исходному состоянию. Такой механизм часто называется транзакционным.

Транзакция — это последовательность действий, которые либо все завершаются успешно, либо происходит какой-то сбой при выполнении отдельного действия, и тогда отменяются результаты всех предыдущих действий этой цепочки. Так вот, валидацию можно выполнять в процессе выполнения транзакции, а последняя проверка может быть выполнена в самом конце транзакции по обработке данных. При этом мы валидируем уже не сами данные, а то состояние, которое получилось после их полной обработки, и если это состояние не удовлетворяет каким-то ограничениям, тогда мы признаём входные данные невалидными и возвращаем всё к исходному состоянию.

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

Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.

После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.

Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.

Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.

Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.

Тестирование валидаторов

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

Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:

Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:

Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:

Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:

А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:

Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:

Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.

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

Заключение

Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.

P.S. Кросспост

habr.com

Валидация — Validation:

— придание законной силы, утверждение, легализация, ратификация
(общегражданское право);

— процесс, позволяющий определить, насколько точно с позиций потенциального пользователя некоторая модель представляет заданные сущности реального мира
(системное программирование);

— процедура, дающая высокую степень уверенности в том, что конкретный процесс, метод или система будет последовательно приводить к результатам, отвечающим заранее установленным критериям приемлемости; в частности, валидация технологических процессов проводится с использованием образцов не менее трех серий реального продукта с целью доказательство и предоставление документального свидетельства, что процесс (в пределах установленных параметров) обладает повторяемостью и приводит к ожидаемым результатам при производстве полупродукта или готового продукта требуемого качества; валидация аналитических методов состоит в определении: точности, воспроизводимости, чувствительности, устойчивости (межлабораторная воспроизводимость), линейности и других метрологических характеристик
(GMP — Надлежащая производственная практика, является обязательным требованием при производстве лекарственных средств).

Применительно к системам менеджмента качества согласно стандартам ISO серии 9000:

Валидация — подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены
(ISO 9000:2005)

Валидация — подтверждение путем экспертизы и представления объективного доказательства того, что особые требования, предназначенные для конкретного применения, соблюдены.
Примечания:

При проектировании и разработке утверждение означает проведение экспертизы продукции с целью определения соответствия нуждам потребителя.
Утверждение обычно осуществляется на конечной продукции в определенных условиях эксплуатации. Оно может быть необходимо на более ранних стадиях.
Термин «утверждено» используется для обозначения соответствующего статуса.
Могут осуществляться многократные утверждения, если предполагается различное использование.

(ISO 8402:1994, п.2.18)

По определению PIC/S, валидация это:
«Действия, которые в соответствии с принципами GMP доказывают, что определенная методика, процесс, оборудование, сырье, деятельность или система действительно приводят к ожидаемым результатам».

Валидация

Исследования по валидации должны способствовать надлежащей практике производства; их следует проводить в соответствии с установленными процедурами. Результаты и заключения должны быть оформлены протоколами.

Если вводят новую производственную рецептуру или новый способ изготовления, то должны быть предприняты действия, демонстрирующие их пригодность для серийного производства. Должно быть доказано, что установленный процесс при использовании специфицированных веществ и оборудования позволяет постоянно получать продукцию требуемого качества.

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

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

Валидация и ее документирование

Цель валидации простая: доказать, что объект валидации действительно приводит к ожидаемым результатам. Другими словами, валидация должна показать, что производитель полностью управляет процессом производства. Валидация является интегральной частью «обеспечения качества», показывая, что производитель понимает причины изменчивости процесса и, главным образом, понимает какие параметры необходимо контролировать для обеспечения стабильности процесса. Эффективная валидация основана на менеджменте риска и современном уровне науки.

Процедуры процесса валидации должны быть зафиксированы в ряде протоколов и результаты валидации должны быть зафиксированы в записях или отчетах.

Эти документы используются в разных формах при получении регистрационного удостоверения и инспекции в соответствии с правилами GMP и так же, для внутренних производственных целей, чтобы руководство организации могло быть уверено в том, что оно контролирует свои процессы. Документация процесса валидации является базой для необходимой регуляции. Но для того, чтобы избежать
той ошибки, которая часто встречается при внедрении принципов GMP в России, мы сознательно обсуждаем процесс документирования валидации в разделе о документации.

Существует довольно серьезная разница между российским и международным подходами. В российских правилах GMP, валидация «заключается в документированном подтверждении соответствия оборудования, условий производства, качества сырья и готового продукта действующим регламентам иили требованиям нормативной документации». Это подход – устаревший. Его последствия – довольно вредные. Из разных публикаций может создаться впечатление, что процесс валидации является не более, чем процессом документирования или, что такие слова как «валидация» «верификация», «квалификация» и «испытание», в самом деле, являются аналогами друг друга. Отсутствие понимания «валидации» укрепляет недопонимание GMP, и создает ситуацию, когда персонал сопротивляется внедрению GMP, просто принимая его как «вечно растущую гору документов».

В GMP EC (и, кстати, GMP FDA) валидация является регулярным изучением систем, процессов, инженерных комплексов и, естественно, самого фармацевтического продукта, чтобы обеспечить высокий уровень уверенности в том, что процессы были должным образом разработаны и находятся под контролем.

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

С точки зрении разработчиков и производителей ЛС валидация способна обеспечить следующие преимущества:

более глубокое понимание процессов и поэтому, уменьшение риска при предотвращении проблем и обеспечение гладкого управления процессом;
снижение стоимости устранения недостатков;
уменьшение риска несоответствия требованиям регуляторных органов.

После полной валидации процесса, возможно, что количество контролируемых параметров в конце процесса уменьшится. Разработчики, полностью понимая те параметры, которые влияют на изменчивость и, следовательно, на стабильность процесса, имеют необходимую информацию для управления процессом, например, через снижение изменчивости или повышение его скорости. Хотя «валидация» является интегральной частью «обеспечения качества», здесь видна взаимосвязь между валидацией и системой менеджмента. Для того чтобы эффективно проводить валидацию, руководство компании должно определить свою политику в данном вопросе. Одним из первых элементов, который инспектор FDA или PIC/S на-мерен проверить, является именно политика валидации.

Из книги «Комментарий к Руководству Европейского Союза по надлежащей практике производства лекарственных средств для человека и применения в ветеринарии.» / Под. ред. С.Н. Быковского, И.А. Василенко, С.В. Максимов. – М.: Изд-во «Перо», 2014

gmpnews.ru

Термин валидация (англ. Validation) используется в различных сферах деятельности человека в несколько различных смыслах. Ключевым моментом в валидации является сверка выставленных требований с необходимыми для достижения определённой (поставленной) цели требованиями. Если же эта цель и есть конечное требование, то возникает циклическая проблема (планирование плана или проблема инициализации) . Сверка требований может происходить на их полноту и/или точность.

Валидацию не следует путать с верификацией.

В технике или в системе менеджмента качества валидация подтверждает, что требования внешнего потребителя или пользователя продукта, услуги или системы удовлетворены. Верификация — это обычно внутренний процесс управления качеством, обеспечивающий согласие с правилами, стандартами или спецификацией. Простой способ запомнить разницу между валидацией и верификацией заключается в том, что валидация подтверждает, что «вы создали правильный продукт» , а верификация подтверждает, что «вы создали продукт так, как и намеревались это сделать» .
[править] Другие определения

Согласно российскому стандарту ГОСТ Р ИСО 9000-2001, который соответствует интернациональному, валидация определена следующим образом:

3.8.5 валидация (en validation; fr validation): Подтверждение на основе представления объективных свидетельств (3.8.1) того, что требования (3.1.2), предназначенные для конкретного использования или применения, выполнены, декларируемые свойства и характеристики подтверждаются, а поставленная цель (предназначение системы, комплекса, устройства и т. д. ) достигнута. Примечания:

1. Термин «подтверждено» используется для обозначения соответствующего статуса.
2. Условия применения могут быть реальными или смоделированными.

Исходя из выше описанного, валидация должна быть определена как:

Валидация: Подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, точно и в полном объёме предопределены, а цель достигнута [

otvet.mail.ru

Что такое валидация данных

Валидация – это процесс проверки данных на соответствие различным критериям. При разработке любого приложения в большинстве случаев разработчику приходится иметь дело с обработкой данных, которые ввел пользователь в соответствующие поля на форме. По разным причинам пользователь может вводить некорректные данные. Например, в поле «Возраст» он по ошибке может указать отрицательное или вовсе нечисловое значение. На практике встречается множество ситуаций, где определенные поля в пользовательском интерфейсе могут содержать только те данные, которые строго соответствуют определенным шаблонам. Если не учитывать подобные ситуации, то в процессе работы приложения могут возникать сбои, связанные с некорректным вводом пользователя. Ошибки могут быть допущены случайно или намеренно. В последнем случае пользователь может вводить некорректные данные с целью вывести приложение из строя и таким образом произвести атаку на приложение. Поэтому каждое приложение, которое работает с данными, которые вводит пользователь (а таких приложений большинство) должно производить предварительную проверку корректности введенных данных. Именно по этой причине каждый разработчик должен быть знаком с механизмом валидации данных, которые указал пользователь.

Существует два вида валидации данных, введенных пользователем.

клиентская валидация;
серверная валидация.

Общий алгоритм валидации данных, введенных пользователем можно представить следующим образом.

www.intuit.ru

Проверка паролей

Одним из наиболее распространенных требований, особенно при разработке корпоративных приложений, является контроль сложности паролей, которые используют пользователи для входа в свою учетную запись. ASP.NET Identity включает класс PasswordValidator, с помощью которого можно настроить систему сложности проверки паролей, используя свойства, перечисленные в таблице ниже:

Свойства, определенные в классе PasswordValidator

Название	Описание
RequiredLength	Задает минимально допустимую длину пароля
RequireNonLetterOrDigit	Если установлено значение true, пароль должен содержать хотя бы один символ, который не является ни буквой ни цифрой
RequireDigit	Если установлено значение true, пароль должен содержать цифры
RequireLowercase	Если установлено значение true, пароль должен содержать строчные символы
RequireUppercase	Если установлено значение true, пароль должен содержать прописные символы

Политика определения паролей задается путем создания экземпляра класса PasswordValidator, установки значений его свойств и использовании этого объекта в качестве значения для свойства PasswordValidator класса UserManager<T> в методе Create:

Я использовал класс PasswordValidator, чтобы определить политику, которая требует не менее шести символов, сочетание прописных и строчных букв. Чтобы протестировать эту функциональность, запустите приложение и перейдите по адресу /Admin/Index, затем нажмите кнопку «Создать» и попытайтесь создать пользователя с пустым паролем. При отправке формы, пароль не пройдет проверку достоверности, в результате отобразится ошибка:

Реализация пользовательской проверки паролей

Возможности встроенной проверки паролей являются достаточными для большинства приложений. Однако, возможно вам потребуется создать сложные проверки достоверности для паролей, выходящие за рамки стандартных свойств класса PasswordValidator. Расширить базовые возможности валидации паролей можно, создав класс, унаследованный от PasswordValidator и переопределяющий его метод ValidateAsync(). Добавьте файл класса CustomPasswordValidator.cs в папку Infrastructure со следующим содержимым:

В этом примере мы переопределили метод ValidateAsync() и вызвали сначала базовую реализацию этого метода для запуска встроенной проверки. Далее мы добавили пользовательскую проверку паролей на предмет того, не содержит ли он последовательности чисел «12345». Свойство Errors объекта IdentityResult доступно только для чтения, поэтому чтобы вернуть список ошибок мы создали новый объект IdentityResult и объединили ошибки из базовой проверки достоверности паролей с ошибками из пользовательской проверки. Я использовал LINQ для соединения этих ошибок.

Следующий пример демонстрирует использование нового класса валидатора:

Чтобы протестировать пользовательскую проверку паролей, попробуйте создать новую учетную запись пользователя с паролем «secret12345». Этот пароль нарушает два правила проверки — одно правило для встроенной проверки, второе — для пользовательской. Обе эти ошибки отобразятся при попытке создать нового пользователя:

Проверка данных пользователя

Более общие проверки могут осуществляться путем создания экземпляра класса UserValidator и использования его свойств из таблицы ниже:

Свойства, определенные в классе UserValidator

Название	Описание
AllowOnlyAlphanumericUserNames	Если задано true, имена пользователей могут содержать только буквы и цифры
RequireUniqueEmail	Требует наличие уникального адреса электронно почты

Выполнение проверки данных пользователя выполняется аналогично проверке паролей — свойству UserValidator класса UserManager<T> присваивается объект UserValidator, с предварительно инициализированными свойствами:

Класс UserValidator принимает обобщенный тип, который указывает на класс описания пользователя (в нашем случает это AppUser). В конструктор класса UserValidator передается экземпляр типа UserManager, для связывания проверки пользовательских данных с классом модели пользователя.

Также как и для проверки паролей, вы можете расширить проверку данных пользователя, создав класс, унаследованный от UserValidator. В качестве примера добавьте файл CustomUserValidator.cs в папку Infrastructure проекта со следующим содержимым:

Конструктор производного класса должен принимать экземпляр класса управления пользователем (UserManager) и вызывать конструктор базового класса для запуска встроенной проверки достоверности. Настраиваемая проверка осуществляется путем переопределения метода ValidateAsync, который принимает экземпляр класса пользователя (IdentityUser) и возвращает объект IdentityResult. В этом примере мы добавили расширенную проверку поля адреса электронной почты, которая должна включать в себя домен «mail.com». В следующем примере мы расширили метод Create класса AppUserManager, добавив пользовательскую проверку:

На рисунке ниже показан пример тестирования этой проверки, когда email-адрес пользователя не содержит домена «mail.com»:

Изменения текста ошибок проверки достоверности

Чуть ранее я говорил, что покажу как изменить тексты стандартных ошибок проверки достоверности. Очевидно, что ошибки на английском языке для русскоязычного приложения недопустимы. Итак, нам необходимо реализовать интерфейс валидатора IIdentityValidator<T>, где T — тип проверяемого поля. Например, рассмотренный выше класс PasswordValidator реализует интерфейс IIdentityValidator<string>, а UserValidator — IIdentityValidator<IdentityUser>. Для примера давайте изменим определение класса CustomUserValidator:

В этом примере мы вручную проверяем заполнение поля и список допустимых символов в имени пользователя. Также необходимо изменить вызов вспомогательного класса валидации в методе Create() класса AppUserManager:

professorweb.ru

Валидация и верификация — что это простыми словами?

Оба понятия связаны с тестированием какого-либо продукта и обеспечением его качества. Если мы будем говорить простым языком, то выведем следующее:

Валидация – гарантированная уверенность производителя в том, что он создал продукт по всем необходимым стандартам.
Верификация – помогает увериться в том, что изделие соответствует всем изначально заданным требованиям к нему.

Рассказывая простыми словами, что это – верификация и валидация, нужно сделать упор и на такие факты:

Для потребителя важнее всего валидация – уверенность в том, что он получает правильный продукт, соответствующий его требованиям.
Для производителя более ценной будет верификация – подтверждение того, что изделие, которое он отправляет на реализацию, отвечает всем необходимым стандартам и нормам.

Еще одно значение

Мы еще разберем различие в понятиях «верификация» и «валидация» в тестировании. Ведь по большому счету они связаны с международными требованиями к проверке, приемке технологий и различной продукции.

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

А те, кто активно пользуются социальными сетями («ВКонтакте», «Одноклассники» и проч.), рано или поздно видят перед собой окошко с просьбой пройти валидацию. Это такая же проверка истинности введенных вами данных. К примеру, на привязанный к аккаунту телефон приходит СМС с кодом, который нужно напечатать в определенное поле, чтобы подтвердить, что вы являетесь владельцем указанного номера.

Таким образом, в данном случае трудно выделить разницу между валидацией и верификации. И то и другое, по сути, здесь является проверкой на указание соответствующих действительности данных. Хотим также указать на факт, что валидацию/верификацию успешно используют разработчики различных вирусов с целью выманивания у вас личной информации. Отчего такие данные следует вводить на надежных ресурсах, с компьютера, защищенного современным качественным антивирусом.

Определение стандарта ИСО 9000:2000

Объяснить простыми словами, что это – верификация и валидация, поможет характеристика этих терминов, данная в документах ИСО (ISO – Международная организация по стандартизации). Здесь мы видим следующее:

Верификация – подтверждение на основе объективных предоставленных фактов того, что установленные нормы были выполнены.
Валидация – подтверждение на основе объективных предоставленных фактов того, что установленные нормы для конкретного применения выполнены.

Вот из этих определений уже вытекает разница валидации и верификации:

Первая процедура проводится только по необходимости. Продукт анализируется в заданных условиях эксплуатации. Результатом будет вердикт: возможно ли его использовать в данной обстановке.
Вторая процедура практически обязательна. Это проверка на соответствие продукта требованиям, которые будут актуальны при любых условиях, при любом использовании.

Прочие определения верификации

Помочь разобраться в теме нам поможет ряд распространенных определений рассматриваемых понятий. Приведем характеристики верификации:

Подтверждение соответствия выпущенного товара, продукта определенным эталонам.
Практически обязательная процедура; сличение характеристик произведенной единицы с рядом заданных требований. Результат – вердикт соответствия или несоответствия последним.
Провозглашение подтверждения, что установленные нормы в отношении изделия были выполнены.
Простыми словами – создан продукт, который соответствует необходимым стандартам.

Прочие определения валидации

Рассмотрим теперь определения валидации:

Практическое определение того, насколько тот или иной продукт соответствует ожиданиям его непосредственных пользователей.
Процедура, которую проводят при необходимости. Это распространенный анализ заданных условий и оценка характеристик продукта касательно его эксплуатации в данной среде. Результат – вывод о возможности использования товара, изобретения в определенной сфере.
Подтверждение соблюдения требований системы стандартов, заказчика, непосредственного пользователя и проч.
Простыми словами – создан правильный продукт, удовлетворяющий потребителя.

Отличия на основе перевода

Определить, в чем разница между валидацией и верификацией, поможет и обращение к переводу этих слов, имеющих английские корни:

Verification – какая-либо проверка.
Validation – придание чему-либо законной силы.

Даже из этого следует, что верификация предшествует валидации, не является конечной. Окончательный вердикт продукту, имеющий законную силу, дает именно последняя.

Отличия верификации и валидации в сравнении

В сравнительной таблице легче обозначить различия этих в чем-то схожих терминов.

Верификация	Валидация
Делаем ли мы продукцию правильно?	Произвели ли мы правильный продукт?
Вся ли функциональность была реализована?	Верно ли функциональность была реализована?
Верификация предшествует валидации: она включает в себя полную проверку правильности написания, производства и прочего сотворения.	Случается уже после верификации — это оценка качества произведенного продукта.
Проводят разработчики.	Проводят тестировщики.
Статистический тип анализа: сравнение с установленными требованиями к продукту.	Динамический тип анализа: продукт тестируется в эксплуатации для выяснения его соответствия нормам.
Объективная оценка: выносится на основе соответствия определенным стандартам.	Субъективная оценка: личная оценка, которую ставит специалист-тестировщик.

Давайте еще немного порассуждаем, чем отличается валидация от верификации, в следующем разделе.

Ключевые различия понятий

Итак, расставим все точки над i. Верификация – это любое тестирование, через которое проходит продукт. Проверка правильности технологии его производства, а также качества изделия. Валидация же — понятие, более близкое к аттестации. Это соответствие каким-то конкретным, а не общим требованиям. Насколько хорош продукт не вообще, а именно для определенного потребителя, заказчика или заданных условий.

Еще можно отметить, что верификация – это бумажное, теоретические тестирование технологии или продукта. Валидация же – реальная, физическая проверка, осуществляемая на практике, в конкретных условиях.

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

Примеры верификации

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

Фармацевтический завод проверяет лекарства на соответствие конкретным требованиям. На вводе в производство устанавливается их безопасность для пациента в определенных дозах, отсутствие эффекта плацебо, неимение возможности проявления губительного привыкания и проч. Таким образом, верификация препаратом пройдена. А валидацию в этом случае проводит уже лечащий доктор: он определяет, поможет ли лекарство конкретному пациенту, не приведет ли его применение к риску для жизни и здоровья этого человека и т. д.

Рассмотрим на примере велосипеда. Проверяем, есть ли руль, сидение, цепи, колеса, тормозная система и проч. Все на месте? Верификация пройдена!

Примеры валидации

Теперь примеры, чем отличается валидация от верификации.

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

На примере того же велосипеда рассмотреть валидацию тоже очень легко. На устройстве можно кататься? Можно затормозить? Можно повернуть вправо, влево? Переключить скорость? Если все возможно, валидация пройдена. Не смогли затормозить, упало сидение, расшатан руль – увы, велосипед данную процедуру не прошел.

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

fb.ru

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

Имейте в виду, что оптимизация лид-форм — это ключевой компонент процесса оптимизации конверсии, и основное внимание здесь следует уделить валидации полей.

Юзабилити лид-форм: эффективные методы повышения конверсии интернет-магазинов

Что такое валидация лид-формы?

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

К примеру, Twitter не позволит вам перейти на следующий этап регистрации, если вы введете адрес электронной почты в неправильном формате:

Когда вы введете адрес почты в том формате, который нужен системе, рядом с полем появится галочка, свидетельствующая о том, что формат введенных данных верен:

Суть валидации — гарантировать введение пользователями данных в формате, требуемым системой (например, адрес почты должен соответствовать стандарту user@example.com, а вот, к примеру, пароль должен содержать не менее 7 символов).

Существуют два основных вида формы валидации:

1. Валидация после отправки данных.
2. Встроенная валидация.

10 простых идей по улучшению конверсии лид-форм

Валидация после отправки данных

Этот вид валидации наиболее распространенный, но вместе с тем далеко не самый удачный. Принцип его работы довольно прост: после заполнения всех необходимых полей пользователь отправляет данные на сервер веб-ресурса (обычно нажатием кнопки «Отправить»), где они и проходят валидацию. Результат проверки возвращается на компьютер пользователя в виде сообщения: если все данные верны, то появится подтверждающее этот факт сообщение, если нет — то сообщение об ошибке.

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

Извините, но вы совершили 8 ошибок при заполнении формы регистрации. Исправьте ошибки, отмеченные ниже, и попробуйте снова.
Ошибки: пароли не совпадают; неправильно введен email-адрес; не указана дата рождения и т.д.

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

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

Пип Лайя (Peep Laya), известный маркетолог и основатель блога ConversionXL, пытался заполнить форму, приведенную выше, чтобы получить смету на предстоящее мероприятие. После валидации формы система сообщила о совершенной ошибке. Строка «Число гостей» требовала ввода конкретного числа, тогда как Пип ввел предполагаемый диапазон гостей (от 50 до 100), что логично на самом деле, поскольку никогда нельзя быть уверенным в том, сколько человек посетит то или иное мероприятие. Как это обычно и бывает, до отправки формы о наличии подобного требования нигде указано не было. В этом-то и заключается основная ошибка разработчиков.

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

Встроенная валидация

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

Хороший пример встроенной валидации — регистрационная форма Twitter. При заполнении полей вы видите либо подтверждающий сигнал (зеленую галочку), либо сигнал, указывающий на наличие ошибки (красный крестик):

Большинство экспертов сходятся во мнении, что встроенная валидация благотворно влияет на опыт взаимодействия с ресурсом (user experience). Вот что говорит о лид-формах Люк Врублевский (Luke Wroblewski), директор по продуктам Google и автор книги «Сначала мобильные!»:

«Лид-формы — не очень приятные собеседники. Они задают кучу вопросов, потом ждут, когда вы на них ответите, и лишь затем говорят что-то свое, как-то реагируют. Этот процесс больше напоминает монолог, чем активное взаимодействие».

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

коэффициент успешного заполнения формы повысился на 22%;
на 22% сократилось число совершенных ошибок;
рейтинг удовлетворенности повысился на 31%;
время выполнения задачи уменьшилось на 41%;
на 47% уменьшилось число фиксаций глаз;
на 22% увеличилось число людей, посчитавших, что заполнение формы стоило затраченных усилий.

Одна из статей веб-ресурса Designmodo посвящена описанию встроенной валидации на уже упомянутом сервисе микроблоггинга Twitter:

«Обаяние хорошо продуманного формата валидации данных в Twitter неотразимо. Информативные сообщения об ошибках появляются рядом с тем полем, где, собственно, совершена ошибка, мгновенно устраняя возникающее раздражение от процесса заполнения формы. Встроенная валидация помогает пользователю понять, что происходит в данный момент — небольшая регистрационная форма как будто пытается вести с ним разговор. Это настоящее откровение! В конце концов, человеку не придется ждать перезагрузки всей страницы, чтобы проверить, заполнена ли форма нужными данными».

Приемы оптимизации лид-формы

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

1. Дополните лид-форму кратким пояснительным текстом (подсказками)

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

Однако текст, который вы размещаете рядом с полями формы, должен быть максимально доступным. Агентство Baymard Institute сообщает, что в ходе проведенного им исследования наиболее успешных интернет-магазинов было выявлено, что 92% из них грешат неадекватным описанием полей лид-форм в процессе подтверждения заказа.

Чтобы избежать путаницы, постарайтесь быть как можно более конкретными в подсказках, как на примере ниже:

С помощью коротких, но предельно ясных пояснений, разработчикам удается ответить на все возможные вопросы со стороны пользователя: как написать свое имя, номер карты и код безопасности. Микротекст помогает посетителям заполнить форму быстрее, с меньшим количеством ошибок.

Джошуа Портер (Joshua Porter), UX-директор в Hubspot, также отмечает невероятную полезность данного инструмента. Узнав, что пользователи испытывают затруднения с заполнением платежной информации, он добавил строку текста, которая сообщала, что информация, вводимая в форму, должна совпадать с информацией, размещенной на их кредитных картах. После этого нововведения проблема исчезла.

Hubspot

«Убедитесь, что вводимая вами информация совпадает с данными вашей кредитной карты»

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

Согласно результатам исследования агентства Baymard Institute, пользователи чувствуют дискомфорт и тревогу, когда при заполнении формы их просят ввести информацию личного характера (например, номер телефона или адрес места жительства) и при этом не объясняют, зачем эта информация нужна. Очевидно, что такой подход чреват высоким уровнем отказов, поскольку далеко не каждый готов предоставить эти данные безвозмездно. В микротексте же вы можете дать ответ на подобные вопросы и снять лишнее напряжение. В частности, следует обратить внимание пользователей на то, для чего вам нужны те или иные данные, для каких целей:

Hubspot

«На этот адрес мы вышлем вам электронное письмо с подтверждением подписки»

2. Будьте аккуратны с сообщениями об ошибках

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

Обратите внимание на то, как реализована система оповещения об ошибке на сайте Meetup.com (социальная сеть). В данном случае неверно заполнено поле почтового индекса:

Meetup

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

3. Будьте тактичны при оповещении об ошибках

Ясно как день: людям не нравятся сообщения об ошибках.

Журнал Smashing Magazine сообщает, что «даже если человек заполнил до 90% лид-формы правильно, но после ее отправки и перезагрузки страницы увидел сообщение об ошибке, он будет чувствовать себя так, словно ничего и не заполнял».

Для начала, не используйте слова с негативным оттенком. Выбросьте из головы все фразы типа «ошибка» и «неправильно».

Самое худшее, что вы можете сделать — это дать человеку почувствовать себя недостаточно умным, чтобы заполнить вашу форму (которая, вероятно, сама по себе слишком запутанная). Вместо того, чтобы фокусировать внимание пользователя на его ошибках, предложите вариант решения проблемы.

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

Ниже — пример, в котором все сделано правильно. Обращаем внимание на то, как Google сообщает своим пользователям о совершенных ими ошибках:

Meetup

Если на вашем сайте реализована встроенная валидация, помните, что кроме оповещения об ошибках, вам нужно как-то сообщать пользователям и о том, что они сделали правильно.

4. Не будьте излишне придирчивы

Один из неприятных моментов, с которым сталкиваются пользователи при заполнении лид-форм — ситуация, когда данные запрашиваются в конкретном формате, а вариативность исключается.

К примеру, если вы запрашиваете у человека дату, разрешите ему ввести год как «16» или «2016» — не нужно ограничивать его каким-то одним вариантов, ведь очевидно, что могут быть использованы оба эти обозначения. Также позвольте людям ставить (/) или (.) между цифрами. Когда вы запрашиваете номер телефона, не требуйте наличия пробелов, скобок или чего-нибудь еще — пусть пользователь введет свой номер телефона так, как ему это удобно.

Если вам нужны данные в определенном формате, объясните это с помощью микротекста, а еще лучше — преобразуйте данные в нужный формат при помощи скрипта.

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

Джеймс Робинсон (James Robinson), автор бестселлера «Будущее сетевого маркетинга», говорит по этому поводу следующее:

«Начните использовать свободную валидацию лид-форм: вместо того, чтобы строго требовать от пользователей ввода данных в конкретном формате, допустите вариативность. Со временем вы поймете, как именно удобно пользователям вводить ту или иную информацию, и приспособитесь под их формат. Это более выигрышно, чем требовать от людей нечто, что подходит вам, но не им».

Особенно это касается паролей. Старайтесь не допускать возникновения такого сценария:

«Поле с паролем не может быть пустым;
Пароль должен содержать от 8 до 16 символов;
В пароле должны быть использованы буквы и цифры;
Пароль должен содержать хотя бы одну цифру или букву;
Не допускается повторения числа или буквы до 3-х раз и т.д.»

5 советов по созданию вашей следующей лид-формы

Превентивные меры

Грамотный сервис и комфортный user experience — это не только своевременные и приятные глазу сообщения об ошибках, но и инструменты, которые помогают пользователям не совершать ошибок вовсе. Вышеперечисленные приемы во многом преследуют ту же цель, но их не всегда бывает достаточно. Ниже перечислены несколько превентивных инструментов, при наличии которых совершить ошибку можно разве что специально.

1. Не следуйте общему правилу

На большинстве сайтов вы можете встретить лид-форму, при заполнении которой (как правило, поля «Пароль») вы не видите вводимые значения: они заменяются звездочками. Как вы понимаете, несмотря на то, что эта практика широко распространена, она далеко не самая удачная, поскольку вызывает проблемы с юзабилити.

Вместо того, чтобы делать как все, экспериментируйте. Например, можете попробовать систему с показом последнего введенного символа в пароле (это просто находка для владельцев смартфонов с маленькими экранами):

2. Показать пароль

Еще в 2009 году на этот аспект обращал внимание и Якоб Нильсен (Jakob Nielsen), основатель консалтингового агентства Nielsen Norman Group, в своей статье «Хватит скрывать пароли» (Stop Password Masking). Он также утверждает, что маскировка пароля приводит к большим проблемам с юзабилити лид-формы. Согласно Нильсену:

пользователи совершают больше ошибок, когда они не видят, какие символы вводят в поле. Поэтому они чувствуют себя недостаточно уверенно и легко могут вовсе отказаться от заполнения формы (что приводит к снижению показателя конверсии);
возникающая неуверенность и неопределенность в итоге приводит к тому, что люди склонны использовать более простые пароли, которые просто взломать. Это заметно снижает степень безопасности, а следовательно — и удовлетворенность вашим сервисом, если вдруг возникнет критическая ситуация.

Взгляните на пример eBay:

Кстати, совсем необязательно требовать от пользователя подтверждения email-адреса при регистрации. Так делают многие сервисы, но это не повод поступать так же. Вместо этого можно последовать примеру Vimeo — запрашивать электронный адрес только один раз:

3. Не используйте плейсхолдеры

Плейсхолдеры выглядят следующим образом:

Они не совсем удобны по следующим причинам:

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

4. Выпадающие меню и всплывающие подсказки

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

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

Вместо того, чтобы выпытывать у пользователя точное число гостей, разработчикам следовало реализовать форму ввода информации в формате того же выпадающего меню, где можно было бы выбрать один из диапазонов (0-50, 50-100, 100-200 и т.д.).

Если есть возможность, то используйте технологию встроенных подсказок. Пример — ниже:

Тонкости настройки лид-форм, которые позволят вашей конверсии взлететь вверх

Заключение

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

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

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

Высоких вам конверсий!

По материалам conversionxl.comImage source Simo Tata

lpgenerator.ru

Источник

Содержание

Фактчекинг: 5 способов проверить информацию
Что это такое?
Как работает фактчекинг?
Основные приемы фактчекинга, которые помогут проверить информацию на 100%
Способы проверки достоверности данных
Что такое валидация данных
Краткие итоги

Фактчекинг: 5 способов проверить информацию

Выполнение любого проекта (студенческого, научно-исследовательского) сводится к тотальной переработке первоисточников, их поиску, изучению и систематизации отобранных фрагментов. Обязательным требованием при написании курсовой, дипломной или научной работы является использование исключительно проверенных данных, которые соответствуют таким требованиям, как актуальность, достоверность и обоснованность.

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

Что это такое?

Фактчекинг представляет собой процедуру проверки всех найденных данных с целью установления их достоверности, актуальности и надежности. Это своего рода «фильтр» материалов, который помогает автору досконально разобраться в конкретной ситуации или вопросе.

Достоверные и ложные факты

В жизнь писателей, редакторов и иных «текстовых профессий» он пришел из журналистики. Притом данный термин (как и многие другие) пришел к нам из-за границы (fact cheking). В дословном переводе «фактчекинг» представляет собой проверку фактов, сбор обоснованных аргументов, которые станут бесспорной доказательной базой любого исследования.

Фактчекинг преследует конкретную цель – отсеять противоречия, искажения и недостоверные материалы, ликвидировать сомнительные ресурсы. Поэтому сегодня он пользуется высоким спросом, как среди студентов, так и среди ученых, исследователей, журналистов и писателей.

Эта процедура основывается на таких правилах, как:

Независимость: исследователь должен сравнивать совершенно разные источники информации сопоставлять их, чтобы выявить: где правда, а где ложь. При этом сопоставлению подлежат сведениях из абсолютно разных источников, которые не оказывают воздействие друг друга, авторы не опирались на труды друг друга и пр.;
Объективность и независимость: исследователь должен быть заинтересован в тщательной проверке фактов, быть требовательным к себе и материалам, не поддаваться влиянию со стороны. Здесь важно иметь холодный разум, не поддаваться эмоциям и иным факторам.

Основополагающими терминами данного направления являются факты и фактоиды. Факты представляют собой сведения, которые были доказаны, обоснованны и общепризнанны. Они обладают определенной значимостью и важностью, являются неоспоримыми. Фактоиды – это те сведения, которые не прошли должной проверки, но при этом были приняты обществом без каких-либо проверок, то есть это несуществующий и «неоправданный» факт. Каждый исследователь должен разбираться в материалах, отличать факты и фактоиды.

Что такое фактчекинг?

Основанная задача фактчекинга — ликвидировать фактоиды и оставить исключительно надежные факты (то есть истину).

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

Как работает фактчекинг?

Основным инструментом фактчекинга является сомнение. Исследователь должен подвергнуть сведения сомнению или критике, перепроверить и доказать их действие: достоверны они или нет, имеются ли противоречия, можно ли на них полагаться. Только после получения точного ответа на поставленные вопросы можно убедиться в том, что перед автором предстали именно факты.

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

Этапы поиска и сбора информации

Опытные эксперты рекомендуют придерживаться следующей схемы фактчекинга, которая позволит быстро и эффективно оценить ресурсы:

Никогда не полагайтесь на один ресурс. В «копилке» у автора должно быть как минимум 3-5 источников информации, которые он будет сопоставлять между собой;
Проверяйте все ресурсы даже те, которые Вам уже были знакомы. Даже если Вы неоднократно обращались к сайту или платформе, важно перепроверять все данные, независимо от репутации и авторитета издания. Нередко с течением времени качество продуктов начинает ухудшаться. Информационная среда – не исключение;
Уточняйте незнакомые Вам фразы и термины, сравнивайте их определение в разных источниках. В научно- исследовательском проекте следует использовать только осмысленные определения и клише, вписывающиеся вы общую структуру и содержание;
Количество – не значит качество. Важно разобраться в материалах, оценить все стороны медали. Изучите мнение не только сторонников теории, но и критиков. Важно исследовать не как можно больше ресурсов, а определить оптимальное количество достоверных фактов, которые лягут в основу новой работы. Такой поход позволит понять достоинства и недостатки материалов, их эффективность и достоверность, принять конкретную позицию и аргументировать ее.

Нужна помощь преподавателя?

Мы всегда рады Вам помочь!

Не доверяйте фейковым страницам и материалам. Важно уметь различать официальные данные, проверенные факты от мифов и былин. В научное исследование в качестве небольшого доказательства можно положить даже новостную статью, главное – тщательно ее перепроверить. Если ее опубликовало малоизвестное издание, а схожих материалов больше не наблюдается, следует насторожиться. Все материалы, вызывающие малейшую долю сомнений уже не будут являться фактами, в связи с чем их применение в проекте и новых разработках невозможно.
Недопустимо поддаваться эмоциям. При изучении материала необходимо обладать «холодным разумом». Важно вникать и оценивать конкретные факты, без изучения лишних деталей, описывающих состояние героев/вещей и пр.

Основные приемы фактчекинга, которые помогут проверить информацию на 100%

Доверяй, но проверяй – лозунг ответственного и компетентного исследователя. Этого принципа следует придерживаться всем: от студентов до ученых. Помочь в написании любого проекта, проведении исследования поможет фактчекинг.

Подбор информационной базы

При подборе информационной базы для любого проекта (курсовая, дипломная, научная и иная работа) важно тщательно изучать, обрабатывать и анализировать найденную информацию. Для этого достаточно пользоваться следующими приемами:

Сравнение и сопоставление: важно изучать разные источники информации и сравнивать их между собой;
Все первоисточники должны быть независимыми: это значит, что необходимо пользоваться кардинально разными изданиями, которые не имеют между собой ничего общего. Так можно сравнивать материалы из научных изданий и СМИ, диссертаций и мнений экспертов и т.д.
Изучаем «за» и «против»: недопустимо изучение проблемы или вопроса только с одного ракурса. Чтобы разобраться в теме, установить конкретные факты, тенденции и закономерности следует изучать различные мнения: сторонников и противников, критиков и пр. В этом случае можно получить полноценную картину об изучаемом явлении, определить достоверные факты. Более того, данный подход позволит диагностировать реальную и актуальную проблему, противоречие, на основе которого автор сможет выдвинуть гипотезу;
Минимизируем данные из социальных сетей и мессенджеров. По статистике доминирующая доля «фейков» и лжи распространяется через социальные сети. Пользоваться данными информационными порталами можно, но с особой осторожностью, ответственностью и максимальным вниманием. Все сведения, полученные из социальных сетей, необходимо неоднократно перепроверять. Лучше всего доверять авторитетным научным изданиям и авторам;
Из любого текста необходимо выделять суть и ключевые моменты, а затем сравнивать их же с другими материалами. Не стоит проводить «словесное сравнение» материалов, кто и как описал. Важно установить истинность суждений.

Таким образом, фактчекинг – это процесс установления истины, перепроверки фактов и выделения проверенной и надежной информации. Он позволяет разобраться в ресурсах, грамотно подобрать достоверные источники информации для будущего исследования, собрать безоговорочную и надежную доказательную базу для подтверждения или опровержения выдвинутой гипотезы.

Пользоваться данным инструментом должны все: школьники, студенты, аспиранты, ученые, известные личности, ораторы и пр. Иначе, используя непроверенные сведения, можно заработать плохую репутацию в научных и иных кругах, прослыть плагиатором или лжецом. За распространение слухов и недостоверных данных, клевету в российском законодательстве предусмотрена административная, гражданско-правовая и уголовная ответственность.

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

Трудности с учебой?

Помощь в написании студенческих и
аспирантских работ!

Источник

Способы проверки достоверности данных

Что такое валидация данных

Валидация – это процесс проверки данных на соответствие различным критериям. При разработке любого приложения в большинстве случаев разработчику приходится иметь дело с обработкой данных, которые ввел пользователь в соответствующие поля на форме. По разным причинам пользователь может вводить некорректные данные. Например, в поле «Возраст» он по ошибке может указать отрицательное или вовсе нечисловое значение . На практике встречается множество ситуаций, где определенные поля в пользовательском интерфейсе могут содержать только те данные, которые строго соответствуют определенным шаблонам. Если не учитывать подобные ситуации, то в процессе работы приложения могут возникать сбои, связанные с некорректным вводом пользователя. Ошибки могут быть допущены случайно или намеренно. В последнем случае пользователь может вводить некорректные данные с целью вывести приложение из строя и таким образом произвести атаку на приложение . Поэтому каждое приложение , которое работает с данными, которые вводит пользователь (а таких приложений большинство) должно производить предварительную проверку корректности введенных данных. Именно по этой причине каждый разработчик должен быть знаком с механизмом валидации данных, которые указал пользователь .

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

Существует два вида валидации данных, введенных пользователем.

клиентская валидация;
серверная валидация.

Общий алгоритм валидации данных, введенных пользователем можно представить следующим образом.

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

Краткие итоги

Источник

Валидация на стороне сервера

Валидация на стороне сервера должна осуществляться независимо от того, включена валидация на стороне клиента или нет. Пользователь может отключить JavaScript или совершить какие-нибудь другие непредвиденные действия, чтобы обойти валидацию на стороне клиента, и сервер останется последней линией защиты наших данных от некорректного ввода. Некоторые правила валидации требуют обработки данных на стороне сервера — топологией сети может быть установлено, что только сервер имеет доступ к внешним ресурсам, необходимым для проверки вводимых данных.

Мы рассмотрим два ключевых понятия. Сначала разберем самый распространенный способ валидации на стороне сервера с ASP.NET MVC, используя Data Annotations. Потом мы исследуем метаданные модели и научимся писать собственные реализации провайдеров метаданных.

Валидация с Data Annotations

Библиотека Data Annotations, впервые реализованная в пакете .NET 3.5 SP1, представляет собой набор атрибутов и классов, определенных в сборке System.ComponentModel.DataAnnotations, которые позволяют добавить метаданные к классам. Метаданные описывают набор правил, с помощью которых можно определить, как проводить проверку конкретных объектов.

Кроме описания правил валидации, атрибуты DataAnnotations используются для реализации новых шаблонных функций, как вы видели в главе 3 на примере атрибутов DisplayName и DataType. Специальные атрибуты для контроля валидации приведены в таблице 6-1.

ASP.NET MVC включает в себя набор классов резервной валидации для всех атрибутов, которые отвечают за выполнение текущей проверки данных. Изучим атрибуты валидации на примере интерфейса, которому необходима валидация. На рисунке 6-1 показана форма ввода Edit с полями Company Name и Email Address.

Таблица 6-1: Атрибуты Data Annotations для валидации

Атрибут	Описание
`CompareAttribute`	Сравнивает значения двух свойств модели. Если они равны, валидация успешно завершена
`RemoteAttribute`	Указывает JQuery Validate, библиотеке валидации на стороне клиента, что она должна вызвать действие для валидации на сервере, и выводит ее результат до отправки формы
`RequiredAttribute`	Указывает, что требуется значение поля данных
`RangeAttribute`	Устанавливает ограничения числового диапазона для значения поля данных
`RegularExpressionAttribute`	Указывает, что значение поля данных должно соответствовать заданному регулярному выражению
`StringLengthAttribute`	Задает максимальное число символов, которые разрешены в поле данных

Рисунок 6-1: Экран Edit с обязательным полем

В нашем приложении Company Name – обязательное для заполнения поле, Email Address — необязательное. Чтобы сделать поле Company Name обязательным, мы используем RequiredAttribute.

public class CompanyInput
{
	[Required]
	public string CompanyName { get; set; }
	[DataType(DataType.EmailAddress)]
	public string EmailAddress { get; set; }
}

Мы добавили RequiredAttribute к свойству CompanyName. Мы также добавили EmailAddress к атрибуту DataTypeAttribute, чтобы воспользоваться пользовательскими шаблонами для адресов электронной почты.

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

<h2>Edit</h2>
@using (Html.BeginForm("Edit", "Home")) {
	@Html.EditorForModel()
	<button type="submit">Submit</button>
}

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

Для более детального управления выводом, мы можем использовать методы расширения валидации HtmlHelper. Расширение ValidationSummary предоставляет сводный список ошибок валидации, который обычно отображается в верхней части формы. Чтобы выводить ошибки валидации для конкретных свойств модели, мы можем использовать метод ValidationMessage, а также ValidationMessageFor, основанный на выражениях.

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

[HttpPost]
public ActionResult Edit(CompanyInput input)
{
	if (ModelState.IsValid)
	{
		return View("Success");
	}
	return View(new CompanyInput());
}

В действии Edit метода POST мы сначала проверяем наличие ошибок в ModelState. Движок валидации MVC помещает ошибки валидации в ModelState, и их отсутствие отражается в свойстве IsValid. Если ошибок нет, мы выводим экран с сообщением об успешном заполнении формы. В противном случае мы отображаем исходный экран Edit, теперь с сообщением об ошибке валидации.

Чтобы продемонстрировать ошибку валидации в этом примере, просто отправим форму, не заполняя поле для названия компании. На этой странице поле Company name является обязательным. Результат показан на рисунке 6-2.

Рисунок 6-2: Ошибка валидации в результате отсутствия названия компании

Когда мы заполним форму, пропустив поле для названия компании, сообщение об ошибке валидации отображается корректно.

Тем не менее, на рисунке 6-2 показана проблема, связанная с сообщением об ошибке валидации и самим экраном. И сообщение об ошибке, и название поля отображаются как «CompanyName» без пробела. Но мы хотим всегда включать пробелы между словами в названиях полей. Исправить название поля можно с помощью DisplayNameAttribute (часть пространства имен System.ComponentModel). Так как принято отображать имена свойств с пробелами между словами, мы расширим встроенный класс ModelMetadataProvider с помощью метода, который будет автоматически добавлять пробелы.

Расширение ModelMetadataProvider

Как мы видели в предыдущей части, многие новые возможности в ASP.NET MVC используют метаданные модели. Шаблоны используют метаданные для отображения элементов ввода и текста, а провайдеры валидации используют метаданные для выполнения валидации.

Если мы хотим, чтобы метаданные для нашей модели извлекались из других источников, помимо Data Annotations, мы должны использовать ModelMetadataProvider.

Листинг 6-1: Абстрактный класс ModelMetadataProvider

public abstract class ModelMetadataProvider
{
	public abstract IEnumerable<ModelMetadata> GetMetadataForProperties
		(object container, Type containerType);

	public abstract ModelMetadata GetMetadataForProperty
		(Func<object> modelAccessor, Type containerType, string propertyName);

	public abstract ModelMetadata GetMetadataForType
		(Func<object> modelAccessor, Type modelType);
}

Класс ModelMetadataProvider содержит методы, которые получают ModelMetadata для каждого члена типа, для конкретно свойства и для частного типа, что показано в листинге 6.1.

Чтобы изменить отображаемый текст для конкретного свойства, нам нужно переопределить поведение базового класса DataAnnotationsModelMetadataProvider. Класс AssociatedMetadataProvider предоставляет общие функции для осуществления сценариев, в которых метаданные извлекаются из традиционных классов, свойств и атрибутов. Производным классам, таким как DataAnnotationsModelMetadataProvider, нужно всего лишь создать ModelMetadata уже уже существующих атрибутов.

В данном примере мы хотим изменить поведение DisplayName в модели метаданных. По умолчанию свойство DisplayName в ModelMetadata приходит от DisplayNameAttribute. Мы все еще хотим поддерживать значение DisplayName через атрибут.

В листинге 6-2 мы расширяем встроенный класс DataAnnotationsModelMetadataProvider создавая DisplayName из имени свойства, разделяя его пробелами.

Листинг 6-2: Пользовательский провайдер метаданных

public class ConventionProvider : DataAnnotationsModelMetadataProvider
{
	protected override ModelMetadata CreateMetadata(
			IEnumerable<Attribute> attributes,
			Type containerType,
			Func<object> modelAccessor,
			Type modelType,
			string propertyName)
	{
		var meta = base.CreateMetadata(attributes, containerType, modelAccessor, modelType, propertyName);
		if (meta.DisplayName == null)
			meta.DisplayName = meta.PropertyName.ToSeparatedWords();
		return meta;
	}
}

Строка 3: Переопределяет CreateMetadata

Строка 10: Вызывает базовый метод

Строка 12: Разделяет слова в имени свойства пробелами

Чтобы создать соответствующую схему соглашения для отображения имен, мы создаем класс, который наследуется от класса DataAnnotationsModelMetadataProvider. Этот класс имеет довольно много встроенных возможностей, так что нам остается только переопределить метод CreateMetadata (строка 3). Базовый класс содержит поведение, которые мы хотим сохранить, поэтому мы сначала вызываем метод базового класса (строка 10) и сохраняем его результаты в локальной переменной. Так как мы могли поместить значение атрибута в DisplayName, теперь мы хотим изменить сценарий только в том случае, если значение DisplayName еще не было установлен. Итак, если оно не было установлено, мы хотим разделить имя свойства на отдельные слова с помощью расширенного метода ToSeparatedWords (строка 12). Наконец, мы возвращаем объект ModelMetadata, содержащий измененное имя.

Метод расширения ToSeparatedWords — довольно простое регулярное выражение для разделения идентификаторов на отдельные слова.

public static class StringExtensions
{
	public static string ToSeparatedWords(this string value)
	{
		if (value != null)
			return Regex.Replace(value, "([A-Z][a-z]?)", " $1").Trim();
		return value;
	}
}

Когда мы создали пользовательский ModelMetadataProvider, мы должны настроить ASP.NET MVC, чтобы его использовать. Такая настройка проводится в файле Global.asax:

protected void Application_Start()
{
	RegisterRoutes(RouteTable.Routes);
	ModelMetadataProviders.Current = new ConventionProvider();
}

Чтобы переопределить провайдер метаданных, мы записываем новый провайдер в свойстве ModelMetadataProviders.Current. Когда настройка проведена, сообщения валидации и названия полей отображаются корректно, как показано на рисунке 6.3.

Рисунок 6-3: Экран Edit с корректно отображающимися названиями полей и сообщением об ошибке.

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

В приведенных примерах до сих пор мы использовали исключительно валидацию на стороне сервера, но ASP.NET MVC включает поддержку двойной валидации и на стороне сервера, и на стороне клиента, которую мы рассмотрим в следующем разделе.

Источник

сентябрь
17
, 2019

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

— добавлять товары с пустыми названиями

— прописывать цены строками

— копипастить портянки текста в описания, хотя мы четко написали в инструкции — не больше 200 символов.

Работать с нашим приложением будут не программисты. Представьте менеджера, которому нужно забить в базу 3 сотни товаров, и это до завтра.
Он не будет изучать нашу инструкцию, он сядет и сразу будет набивать по списку. Так сделает любой нормальный человек.

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

Валидация на клиенте и сервере. В чем разница?

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

— юзер пытается добавить товар с пустым названием

— юзер забыл указать цену товара

— юзер вбивает длинное описание, хотя допускается максимум 200 символов.

Все это можно проверить в клиентской части приложения с помощью javascript.

Валидация на сервере — это все то, что можно проверить на клиенте, плюс некоторые специфичные вещи, часто связанные с базой. Например,

— юзер пытается добавить уже существующий товар

— юзер пытается удалить категорию, хотя в ней есть какие-то товары

— юзер пытается удалить бренд, но у него нет прав доступа на это

Все эти вещи проверяются на бекенде, клиент о них не знает.

Отмечу 2 момента:

— стоит по максимуму валидировать данные на клиенте

— дублировать эти же проверки на сервере.

Зачем это нужно?

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

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

Вырисовывается простое правило: валидировать на клиенте нужно для нормальных людей, а дублировать те же проверки на сервере — для нехороших ботов и взломщиков.

Валидация в нашей админке интернет-магазина

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

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

Мы проработаем форму добавления брендов, которую сделали в прошлом уроке.
Сейчас мы можем добавить любой бренд, потому что никаких проверок нет. Исправим это и будем проверять такие вещи:

— не пустой ли бренд

— не превышает ли бренд 20 символов (практического смысла мало, но для примера нормально)

— существует ли этот бренд в базе

— нет ли ошибки в запросе (неверный роутер, проходили в третьем уроке)

— общие ошибки, например, сервис недоступен, бекенд лежит

Первые 2 проверки будем делать на клиенте, следующие 2 — на сервере. Пятая — это все невошедшие ошибки, например, упавший ajax-запрос или 500-ка от сервера.

Дублировать клиентские проверки на сервере мы не будем. Они очень простые и легко реализуются на php, не будем перегружать код.
Другие серверные ошибки, номер 3 и 4, уже реализованы в третьем уроке, когда мы готовили api для админки.

Общая схема обработки ошибок

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

Чтобы понимать, какая именно ошибка произошла, добавим такое понятие — код ошибки. Например, на скриншоте код «brand_exists», что означает, бренд уже существует.
Это проверка серверная, но красное сообщение об этом не знает.
Код ошибки — единственное, на что будет ориентироваться это сообщение и все равно, откуда он придет, при клиентской валидации или с ответом от сервера.
Тексты сообщений мы будем брать из отдельного конфига. Теперь давайте сделаем это на практике.

Валидация на клиенте

Откроем компонент BrandsNew.vue и добавим новое поле errorCode, в раздел data. Это тот самый код, который определяет наличие ошибки. По умолчанию — пустая строка. То есть вот так

    data () {
        return {
            visible: false,
            newBrand: '',
            // Новое поле
            errorCode: ''
        }
    }

Добавим еще вычисляемое логическое поле isError, которое покажет, если ли в данный момент ошибка

    computed: {
        isError () {
            return this.errorCode !== '';
        }
    }

Дальше нам нужно вывести сообщение об ошибки в окне добавления бренда. Добавим такой код между инпутом-брендом и кнопкой Добавить

    Ошибка: {{errorCode}}

Это выделенный красным текст, пример взяли из библиотеки minicss. Напоминаю, наше приложение на этом css-фреймворке. Чуток поправим стили, добавим в style

    mark {
        display: block;
        margin: 5px 0 10px 5px;
    }

Но вернемся к разметке. v-if=»isError» означает, что сообщение будем выводить только, когда есть ошибка, логично. А в тексте сообщения выведем пока код ошибки — {{errorCode}}.
Сначала убедимся, что наша схема работает, а потом заменим бездушный errorCode нормальным текстом.

Итак, errorCode у нас есть, нужны методы для работы с ним. Один метод будет устанавливать код, другой очищать. Добавим в раздел methods

    setError (errorCode) {
        this.errorCode = errorCode;
    },
    clearError () {
        this.errorCode = '';
    }

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

Базовая подготовка сделана, пора заняться самой валидацией. Напомню, мы будем проверять, что новый бренд не пустой и что не длиннее 20 символов.
Метод валидации будет выполнять эти проверки и в случае ошибкок устанавливать соответствующий код codeError. Вот так выглядит метод validate

    validate (brand) {
        if (brand === '') {
            this.setError('brand_empty');
            return false;
        }
        if (brand.length > 20) {
            this.setError('brand_long_title');
            return false;
        }
    
        // Если валидация прошла успешно
        this.clearError();
        return true;
    }

Два простых if-а, которые проставляют нужные коды brand_empty или brand_long_title. А в случае успеха дергаем метод clearError, чтобы сбросить ошибку, если она была до этого.
Например, юзер ввел правильно инфу со второго раза.

Важный момент. Помимо установки codeError мы возвращаем true или false в зависимости от итога валидации.
Нам это нужно, чтобы понять, отправлять ли запрос на сервер с добавлением бренда или же ждать, пока юзер введет бренд правильно.

Посмотрим, какой метод добавления бренда мы написали раньше

    addBrand () {
        this.$store.dispatch('brands/addBrand', this.newBrand);
        this.newBrand = '';
        this.closeModal();
    }

Все просто, вызываем действие через dispatch, очищаем инпут с названием и закрываем модалку. Этот код нужно чуть переделать, вызывать действие только если валидация прошла успешно.
Добавим условие if

    addBrand () {
        if (this.validate(this.newBrand)) {
            this.$store.dispatch('brands/addBrand', this.newBrand);
            this.newBrand = '';
            this.closeModal();
        }
    }

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

Валидация на сервере

С серверными проверками есть свои особенности.

Во-первых, на клиенте мы генерили коды ошибок сами, а для серверных нужно дождаться ответа и получить их из респонса.
Да, мы эти коды (brand_exists и invalid_router) сами сделали в уроке по API. Но вообще мы можем даже и не знать, что за коды нам возвращает бекенд.

Во-вторых, есть интерфейсный момент. Сейчас в методе addBrand сразу после dispatch мы очищаем поле бренда и закрываем модалку.
Это годится, если бренд успешно добавлен и никуда не годится, если сервер вернул ошибку.
Значит, мы должны не просто дернуть dispatch, а дождаться ответа от сервера и только потом решать, что делать.
Если ответ 200 и бренд добавлен, то закрывать модалку, а если ошибка, то выводить ее и оставлять модалку.

Если бы мы писали приложение на jquery, то сделали бы примерно так

    $.ajax({
        url: '',
        data: '',
        success: function() {
            // очищаем поле бренда и закрываем модалку
        },
        error: function() {
            // парсим код ошибки и выводим красное сообщение в модалке
        }
    });

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

Начнем с действия addBrand. Открываем файл store/modules/brands.js и смотрим, как реализовано сейчас

    addBrand (context, newBrand) {
        const data = 'title=' + newBrand;

        axios
            .post('/admin/api/v1/brands', data)
            .then(response => {
                context.commit('ADD_BRAND', response.data)
            });
    }

Отправляем запрос на сервер через axios и в случае успеха вызываем мутацию ADD_BRAND. Нам нужно сделать то же самое, только при этом еще и возвращать промис. Вот так

    addBrand (context, newBrand) {
        const data = 'title=' + newBrand;

        return new Promise((resolve, reject) => {
            axios
                .post('/admin/api/v1/brands', data)
                .then(response => {
                    context.commit('ADD_BRAND', response.data);
                    resolve(response);
                }, error => {
                    reject(error);
                });
        });
    }

Это стандартная заготовка для промисов. resolve и reject — это функции, которые выполняются соответственно при успехе и ошибке.
А что именно делают эти функции, будем решать уже в другом месте — опять в компоненте BrandsNew, в методе addBrand. Немного изменим код.

Было

    addBrand () {
        if (this.validate(this.newBrand)) {
            this.$store.dispatch('brands/addBrand', this.newBrand);
            this.newBrand = '';
            this.closeModal();
        }
    }

Стало

    addBrand () {
        if (this.validate(this.newBrand)) {
            this.$store.dispatch('brands/addBrand', this.newBrand).then(
                response => {
                    this.newBrand = '';
                    this.closeModal();
                },
                error => {
                    let resp = error.response;
                    let errorCode = (resp && resp.data && resp.data.code) ? resp.data.code : 'unknown_error';
                    this.setError(errorCode);
                });
        }
    }

Кода прибавилось, но немного. В метод resolve попадает

    response => {
        this.newBrand = '';
        this.closeModal();
    }

Параметр response нам не нужен, просто для наглядности. Получается, если запрос прошел успешно, бренд добавлен, то очищаем поле в модалке и саму модалку закрываем.
При ошибке выполняется другое

    error => {
        let resp = error.response;
        let errorCode = (resp && resp.data && resp.data.code) ? resp.data.code : 'unknown_error';
        this.setError(errorCode);
    });

Здесь параметр error уже нужен — это ответ от сервера, который нужно распарсить и вытащить код ошибки. Разберем по порядку. В первой строке пишем в переменную resp ответ от сервера.
Дальше идет диковатая конструкция resp && resp.data && resp.data.code. Зачем так сложно?
Ведь мы возвращаем ответ с бекенда в виде { code: ‘код ошибки’, … }, то есть поле code там будет всегда. Не совсем.
Код будет, но только для тех случаев, когда наш бекенд нормально обработает ошибку. Например, найдет, что бренд уже существует, или невалидный роутер (ошибка в запросе, в урле).
Если же бекенд просто лежит и вернет нам 500-ку, то в error.response может прийти null или пустая строка. Поэтому resp.data.code выкинет нам ошибку в консоль и поломает работу.

Поэтому именно здесь мы подстилаем соломку и проверяем всю цепочку error.response.data.code.
Только если data.code действительно существует, то мы понимаем, что эту ошибку вернул наш бекенд и в errorCode мы записываем валидное значение.
А в противном случае мы понимаем, что случилась какая-то хрень и поэтому ставим unknown_error. Типа «случилась непонятная хрень». Так и напишем пользователю.

Задача программиста как можно меньше пугать юзеров непонятными ошибками и стараться по максимуму обрабатывать их руками.
Другое дело, что пользователям вообще по фигу, лежит ли у вас бекенд, упала ли база и кто-то накосячил в коде. Ему важно, что приложение не работает и все.
Поэтому есть смысл не перегружать юзера техническими деталями, а выдать общую ошибку и попросить попробовать позже. Естественно, предполагается, что мы уже устраняем косяки и поднимаем бекенд.

Это все, что касается валидации на сервере. Можно проверять, попытаться добавить существующий бренд или изменить урл /admin/api/v1/brands на какой-нибудь левый.
Если все сделали правильно, то при добавлении бренда будет уходить запрос на сервер, возвращаться ошибка и модалка не закроется, а выведет код.

Когда мы будем тестировать работу, то заметим одну визуальную неприятность. Допустим, попытались мы добавить пустой бренд, нам выскочила ошибка brand_empty.
Изменяем бренд в инпуте, а ошибка так и торчит. Бесит. Давайте добавим одну строчку, чтобы при установке фокуса в инпуте ошибка пропадала. Теперь инпут будет выглядеть так

@focus=»clearError» — вот и пригодился метод clearError!

Вывод нормального сообщения об ошибке вместо кода

Коды ошибок у нас есть, осталось задать им адекватные тексты. Можно сделать это и в компоненте BrandsNew, но мы поступим интереснее.
Заведем в папке admin/vue/src папку configs, а в ней файлик brands.js. Давно было пора, потому что хорошее дело — выносить подобные вещи в конфиги, а не держать их в компонентах.
В файлике-конфиге напишем так

    export default {
        errors: [{
            code: 'brand_empty',
            message: 'Бренд не может быть пустым'
        }, {
            code: 'brand_long_title',
            message: 'Название не должно превышать 20 символов'
        }, {
            code: 'brand_exists',
            message: 'Бренд с таким названием уже существует'
        }, {
            code: 'invalid_router',
            message: 'Ошибка запроса. Попробуйте еще раз'
        }, {
            code: 'unknown_error',
            message: 'Неизвестная ошибка. Попробуйте позже'
        }]
    }

Просто массив из двух полей: код ошибки и текст сообщения. Можно было обойтись объектом, чтобы не бегать по массиву. Но на практике такие простые конфиги часто разрастаются.
То появится тултип с подробным описанием ошибки, то для каждой ошибки нужен будет свой цвет или еще какая-то фигня. Или вместо текстового кода мы решим использовать числовой.
В общем, чтобы не приходилось переделывать структуру конфига, сразу будем использовать массив объектов — в него добавлять новые поля безопасней.

Идем обратно в компонент BrandsNew. В теге script импортируем lodash и конфиг брендов

    import _ from 'lodash';
    import config from '../configs/brands';

Создаем новое вычисляемое поле в computed

    errorMessage () {
        return this.errorCode !== ''
            ? _.find(config.errors, { code: this.errorCode }).message
            : '';
    }

Это и есть сообщение об ошибке, которое берется из конфига по нужному коду. Осталось воткнуть его в разметку вместо errorCode. Вот так

    {{errorMessage}}

Вот теперь все. У нас есть рабочая схема, по которой мы обрабатываем и клиентские, и серверные ошибки, используя один формат данных.
Теперь чтобы добавить новую проверку, достаточно будет воткнуть ее в метод validate, если проверка клиентская, и в php-шный код, если серверная.
Главное, вернуть с бекенда json формата { code: ‘код ошибки’, … }. И добавить новый объект в конфиг, чтобы показывать адекватные тексты пользователям.

До встречи в следующих уроках.

Все уроки админки на vue.js

Анонсы статей, обсуждения интернет-магазинов, vue, фронтенда, php, гита.

Истории из жизни айти и обсуждение кода.

Источник

Пример реализации валидации входных данных веб-сервиса на стороне сервера с использованием reflection.

Используемые технологии и библиотеки

Apache CXF 3.1.6
Spring MVC 4.3.0.Release

1. Описание задачи

Добавить проверку (валидацию) на стороне сервера входящих данных от веб-сервиса используя рефлексию.

2. Структура проекта

Эта статья продолжает код, который описан в статье — Обработка ошибок в SOAP веб-сервисе на стороне сервера. В этой части был добавлен интерфейс ValidationErrorMsg, который описывает новую аннотацию. Валидация будет описана в классе HelloSoap.

3. Validation by reflection

Распространенной задачей при использовании веб-сервисов является валидация данных, которые передаются клиенту. Мы рассмотрим простой случай прихода некорректных значений для объекта Goods из нашей модели данных (будет отсутствовать требуемый параметр name).

package ru.javastudy.ws.soap;

import ru.javastudy.ws.annotations.ValidationErrorMsg;

import ru.javastudy.ws.exceptions.MyWebserviceException;

import ru.javastudy.ws.model.Goods;

import javax.jws.WebService;

import javax.xml.bind.annotation.XmlElement;

import java.lang.reflect.Field;

/**

* Created for JavaStudy.ru on 10.06.2016.

@WebService(endpointInterface = «ru.javastudy.ws.soap.WebserviceSEI»,

serviceName = «HelloSoap»)

public class HelloSoap implements WebserviceSEI {

.....

@Override

public Goods createGoods(String id, String name) throws MyWebserviceException {

Goods goods = new Goods();

goods.setId(Integer.valueOf(id));

validateValues(goods, Goods.class);

return goods;

}

private void validateValues(Object object, Class<?> clazz) throws MyWebserviceException {

if (object == null) {

if (clazz.isAnnotationPresent(ValidationErrorMsg.class)) {

throw new MyWebserviceException(clazz.getAnnotation(ValidationErrorMsg.class).message());

}

for (Field field : clazz.getDeclaredFields()) {

if (field.isAnnotationPresent(ValidationErrorMsg.class)) {

field.setAccessible(true);

try {

if (field.getAnnotation(XmlElement.class).required()

&& ( field.get(object) == null || field.get(object).equals(«»)) ) {

throw new MyWebserviceException(field.getAnnotation(ValidationErrorMsg.class).message());

}

} catch (IllegalAccessException e) {

e.printStackTrace();

}

Сервер предоставляет веб-метод createGoods() у которого есть два выходных параметра — id и name. Прежде чем создавать товар, необходимо удостовериться, что введенные данные от клиента верны. В противном случае мы должны передать клиенту информацию о том, какие именно данные он ввел не правильно и почему мы не можем исполнить его запрос. Причем эта информация должна быть информативной, а не просто трейс java ошибки, которую кроме программистов никто не поймет.

В данном примере намеренно не вызывается goods.setName(name) и следовательно у товара будет не инициализирован один параметр, который мы отметим как обязательный.

3.1. Goods — проверяемая модель

В этом классе мы добавим самописную аннотацию @ValidationErrorMsg, а также стандартную @XmlElement.

package ru.javastudy.ws.model;

import ru.javastudy.ws.annotations.ValidationErrorMsg;

import javax.xml.bind.annotation.XmlAccessType;

import javax.xml.bind.annotation.XmlAccessorType;

import javax.xml.bind.annotation.XmlElement;

import javax.xml.bind.annotation.XmlRootElement;

import java.io.Serializable;

/**

* Created for JavaStudy.ru on 11.06.2016.

@XmlRootElement(name = «goods»)

@XmlAccessorType(XmlAccessType.FIELD)

@ValidationErrorMsg(message = «goods can not be empty»)

public class Goods implements Serializable {

private int id;

@XmlElement(required = true)

@ValidationErrorMsg(message = «name can’t be empty»)

private String name;

public Goods() {

}

public Goods(int id, String name) {

this.id = id;

this.name = name;

}

public int getId() {

return id;

}

public void setId(int id) {

this.id = id;

}

public String getName() {

return name;

}

public void setName(String name) {

this.name = name;

}

@Override

public String toString() {

return «Goods{« +

«id=» + id +

«, name='» + name + »’ +

‘}’;

}

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

3.2 @ValidationErrorMsg

Одним из приемов при валидации данных является создание собственной аннотации, в которой можно описать необходимые методы. В нашем случае мы опишем один метод, который будет выдавать понятное человеку сообщение вместо exception stack trace.

package ru.javastudy.ws.annotations;

import java.lang.annotation.ElementType;

import java.lang.annotation.Retention;

import java.lang.annotation.RetentionPolicy;

import java.lang.annotation.Target;

/**

* Created for JavaStudy.ru on 18.06.2016.

@Retention(value = RetentionPolicy.RUNTIME)

@Target(value = {ElementType.FIELD, ElementType.TYPE})

public @interface ValidationErrorMsg {

public String message();

}

Сначала мы указываем жизненный цикл аннотации — она будет видна на этапе работы программы (в runtime). Далее мы описываем к чему будет применятся аннотация.

3.4. Reflection

Вернемся к валидации товара, в котором не было записано его название (поле name). Для этого в классе HelloSoap есть метод validateValues.

private void validateValues(Object object, Class<?> clazz) throws MyWebserviceException {

if (object == null) {

if (clazz.isAnnotationPresent(ValidationErrorMsg.class)) {

throw new MyWebserviceException(clazz.getAnnotation(ValidationErrorMsg.class).message());

}

for (Field field : clazz.getDeclaredFields()) {

if (field.isAnnotationPresent(ValidationErrorMsg.class)) {

field.setAccessible(true);

try {

if (field.getAnnotation(XmlElement.class).required()

&& ( field.get(object) == null || field.get(object).equals(«»)) ) {

throw new MyWebserviceException(field.getAnnotation(ValidationErrorMsg.class).message());

}

} catch (IllegalAccessException e) {

e.printStackTrace();

}

В него передается объект и класс этого объекта. В случае, если объект не существует, то мы проверяем у класса наличие аннотации ValidationErrorMsg. Т.к. для нашего класса Goods эта аннотация существует, то будет выброшено исключение с записанным значением в методе message.

@ValidationErrorMsg(message = «goods can not be empty»)

public class Goods implements Serializable {

...

Если выше с классом всё в порядке, то переходим к проверке полей данного класса. Мы получаем доступ к каждому полю и проверяем у него аннотацию XmlElement.required(). Если такая аннотация есть и поле пустое, то выбрасываем исключение с значением message для этого поля.

@XmlElement(required = true)

@ValidationErrorMsg(message = «name can’t be empty»)

private String name;

4. Запуск и проверка работы валидации

Для упрощения сервер и клиент были объединены в один проект. Для запуска серверной части необходимо запустить веб-сервер (в проекте, доступном в конце статьи используется Tomcat). Для запуска клиентской части нужно выполнить метод JavaStudyWS.main();

package ru.javastudy.ws.main;

import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;

import ru.javastudy.ws.exceptions.MyWebserviceException;

import ru.javastudy.ws.model.Goods;

import ru.javastudy.ws.soap.WebserviceSEI;

/**

* Created for JavaStudy.ru on 09.06.2016.

public class JavaStudyWS {

public static void main(String[] args) {

testSOAPFromClient();

}

/**

* create client and test soap service

private static void testSOAPFromClient() {

String soapServiceUrl = «http://localhost:8080/soap/webserviceSEI»;

JaxWsProxyFactoryBean factoryBean = new JaxWsProxyFactoryBean();

factoryBean.setServiceClass(WebserviceSEI.class);

factoryBean.setAddress(soapServiceUrl);

WebserviceSEI webserviceSEI = (WebserviceSEI) factoryBean.create();

Goods result = null;

try {

result = webserviceSEI.createGoods(«123», «SomeName»);

} catch (MyWebserviceException e) {

e.printStackTrace();

}

System.out.println(«Result: « + result);

}

В результате увидим следующую ошибку:

Connected to the target VM, address: ‘127.0.0.1:64914’, transport: ‘socket’

июл 02, 2016 5:34:04 PM org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean buildServiceFromClass

INFO: Creating Service {http://soap.ws.javastudy.ru/}WebserviceSEIService from class ru.javastudy.ws.soap.WebserviceSEI

Result: null

<strong>ru.javastudy.ws.exceptions.MyWebserviceException: name can‘t be empty</strong>

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:423)

at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshallException(JAXBEncoderDecoder.java:522)

at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:663)

at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:179)

at org.apache.cxf.interceptor.ClientFaultConverter.processFaultDetail(ClientFaultConverter.java:155)

at org.apache.cxf.interceptor.ClientFaultConverter.handleMessage(ClientFaultConverter.java:82)

at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)

at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112)

at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)

at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)

at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)

at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)

at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1670)

at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1551)

at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1348)

at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)

at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)

at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)

at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)

at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)

at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)

at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)

at com.sun.proxy.$Proxy40.createGoods(Unknown Source)

at ru.javastudy.ws.main.JavaStudyWS.testSOAPFromClient(JavaStudyWS.java:31)

at ru.javastudy.ws.main.JavaStudyWS.main(JavaStudyWS.java:14)

Аналогично можно попробовать не создать класс вообще и тогда увидите в сообщении goods can not be empty.

Исходный код

4. WS Validation

7562 Total Views 3 Views Today

Источник

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

Проверка и обработка исключений

Когда мы начали обсуждать нашу проблему, одна вещь появилась очень быстро. Что такое проверка и что такое обработка исключений? Например, в форме регистрации пользователя у нас есть некоторые правила для пароля (он должен содержать как цифры, так и буквы). Если пользователь вводит только буквы, это проблема проверки или исключения. Должен ли пользовательский интерфейс проверить это или просто передать его бэкэнду и поймать какие-либо исключения, которые могут быть выброшены?

Мы пришли к общему выводу, что валидация относится к правилам, определенным системой и сверенным с данными, предоставленными пользователем. Проверка не должна заботиться о том, как работает бизнес-логика или как работает система в этом отношении. Например, наша операционная система может ожидать, без каких-либо протестов, пароль, состоящий из простых букв. Однако мы хотим применить комбинацию букв и цифр. Это случай для проверки, правило, которое мы хотим навязать.

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

Проверка в пользовательском интерфейсе

Теперь, когда мы ясно дали понять, каковы наши цели, давайте посмотрим несколько примеров, основанных на той же идее формы регистрации пользователя.

Проверка в JavaScript

Для большинства современных браузеров JavaScript – это вторая натура. В ней почти нет веб-страницы без некоторой степени JavaScript. Хорошей практикой является проверка некоторых основных вещей в JavaScript.

Допустим, у нас есть простая форма регистрации пользователя в index.php , как описано ниже.

<!DOCTYPE html>

<html>

<head>

<title>User Registration</title>

</head>

<body>

<h3>Register new account</h3>

<form>

Username:

<br/>

<br/>

Password:

<br/>

<br/>

Confirm:

<br/>

<br/>

</form>

</body>

</html>

Это выведет что-то похожее на изображение ниже:

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

Для начала нам нужно немного обновить наш HTML-код.

Username:

<br/>

<br/>

Password:

<br/>

<br/>

Confirm:

<br/>

<br/>

</form>

Мы добавили имена в поля ввода пароля, чтобы мы могли их идентифицировать. Затем мы указали, что при отправке форма должна возвращать результат функции validatePasswords() . Эта функция – JavaScript, который мы напишем. Подобные простые сценарии можно сохранить в файле HTML, другие, более сложные, должны быть в собственных файлах JavaScript.

function validatePasswords(form) {

if (form.password.value !== form.confirm.value) {

alert(“Passwords do not match”);

return false;

}

return true;

}

</script>

Единственное, что мы здесь делаем, – это сравниваем значения двух полей ввода с именами « password » и « confirm ». Мы можем ссылаться на форму по параметру, который мы посылаем при вызове функции. Мы использовали « this » в onsubmit формы, поэтому сама форма отправляется в функцию.

Если значения совпадают, будет возвращено значение true и форма будет отправлена, в противном случае будет показано предупреждающее сообщение о том, что пароли не совпадают.

Проверка HTML5

Хотя мы можем использовать JavaScript для проверки большинства наших входных данных, в некоторых случаях мы хотим пойти по более простому пути. Некоторая степень проверки ввода доступна в HTML5, и большинство браузеров рады применить их. Использование проверки HTML5 проще в некоторых случаях, хотя и предлагает меньшую гибкость.

<head>

<title>User Registration</title>

<style>

input {

width: 200px;

}

input:required:valid {

border-color: mediumspringgreen;

}

input:required:invalid {

border-color: lightcoral;

}

</style>

</head>

<body>

<h3>Register new account</h3>

Username:

<br/>

<br/>

Password:

<br/>

<br/>

Confirm:

<br/>

<br/>

Email Address:

<br/>

<br/>

Website:

<br/>

<br/>

</form>

</body>

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

Имя username ввода текста просто необходимо. Он будет проверяться с любой строкой длиннее нуля символов.
Поле адреса электронной почты имеет тип « email », и когда мы указываем атрибут « required », браузеры применяют проверку к полю.
Наконец, поле сайта имеет тип ” url “. Мы также указали атрибут « pattern », где вы можете написать свои регулярные выражения, которые проверяют обязательные поля.

Чтобы информировать пользователя о состоянии полей, мы также использовали немного CSS, чтобы закрасить границы входных данных красным или зеленым, в зависимости от состояния требуемой проверки.

Проблема с проверками HTML заключается в том, что разные браузеры ведут себя по-разному, когда вы пытаетесь отправить форму. Некоторые браузеры просто применяют CSS для информирования пользователей, другие вообще запрещают отправку формы. Я рекомендую вам тщательно протестировать HTML-проверки в разных браузерах и, при необходимости, также предоставить запасной вариант JavaScript для тех браузеров, которые недостаточно умны.

Проверка в моделях

В настоящее время многие знают о предложении Роберта С. Мартина о чистой архитектуре, в котором инфраструктура MVC предназначена только для представления, а не для бизнес-логики.

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

Мы не будем устанавливать несколько веб-платформ MVC, чтобы продемонстрировать, как проверять наши предыдущие формы, но вот два приблизительных решения в Laravel и CakePHP.

Валидация в модели Laravel

Laravel разработан таким образом, чтобы у вас было больше доступа к проверке в контроллере, где у вас также есть прямой доступ к вводу от пользователя. Встроенный валидатор предпочитает использовать там. Однако в Интернете есть предположения, что проверка в моделях все еще является хорошей вещью в Laravel. Полный пример и решение Джеффри Уэй можно найти в его хранилище Github .

Если вы предпочитаете написать собственное решение, вы можете сделать что-то похожее на модель ниже.

class UserACL extends Eloquent {

private $rules = array(

‘userName’ => ‘required|alpha|min:5’,

‘password’ => ‘required|min:6’,

‘confirm’ => ‘required|min:6’,

’email’ => ‘required|email’,

‘website’ => ‘url’

);

private $errors;

public function validate($data) {

$validator = Validator::make($data, $this->rules);

if ($validator->fails()) {

$this->errors = $validator->errors;

return false;

}

return true;

}

public function errors() {

return $this->errors;

}

Вы можете использовать это на своем контроллере, просто создав объект UserACL и UserACL validate. Вероятно, в этой модели у вас также будет метод « register », и register просто делегирует уже проверенные данные вашей бизнес-логике.

Валидация в модели CakePHP

CakePHP также поддерживает валидацию в моделях. Он имеет обширную функциональность проверки на уровне модели. Вот как будет выглядеть проверка для нашей формы в CakePHP.

class UserACL extends AppModel {

public $validate = [

‘userName’ => [

‘rule’ => [‘minLength’, 5],

‘required’ => true,

‘allowEmpty’ => false,

‘on’ => ‘create’,

‘message’ => ‘User name must be at least 5 characters long.’

‘password’ => [

‘rule’ => [‘equalsTo’, ‘confirm’],

‘message’ => ‘The two passwords do not match.

]

];

public function equalsTo($checkedField, $otherField = null) {

$value = $this->getFieldValue($checkedField);

return $value === $this->data[$this->name][$otherField];

}

private function getFieldValue($fieldName) {

return array_values($otherField)[0];

}

Мы только частично проиллюстрировали правила. Достаточно выделить силу проверки в модели. CakePHP особенно хорош в этом. Он имеет большое количество встроенных функций проверки, например minLength и различные способы обеспечения обратной связи с пользователем. Более того, такие понятия, как « required » или « allowEmpty », на самом деле не являются правилами валидации. Cake будет смотреть на них при создании вашего представления и помещать проверки HTML также в поля, отмеченные этими параметрами. Однако правила хороши и могут быть легко расширены простым созданием методов в классе модели, как мы делали для сравнения двух полей пароля. Наконец, вы всегда можете указать сообщение, которое вы хотите отправить в представления в случае сбоя проверки. Подробнее о проверке CakePHP в кулинарной книге .

Проверка в целом на уровне модели имеет свои преимущества. Каждая структура обеспечивает легкий доступ к полям ввода и создает механизм уведомления пользователя в случае сбоя проверки. Нет необходимости в инструкциях try-catch или каких-либо других сложных шагах. Проверка на стороне сервера также гарантирует, что данные будут проверены, несмотря ни на что. Пользователь не может больше обманывать наше программное обеспечение, как с помощью HTML или JavaScript. Конечно, каждая проверка на стороне сервера сопряжена со стоимостью сетевого обмена и вычислительной мощностью на стороне провайдера, а не на стороне клиента.

Бросая исключения из бизнес-логики

Последний этап проверки данных перед их передачей в систему находится на уровне нашей бизнес-логики. Информация, которая попадает в эту часть системы, должна быть достаточно очищена, чтобы ее можно было использовать. Бизнес-логика должна проверять только те случаи, которые для нее критичны. Например, добавление пользователя, который уже существует, является случаем, когда мы генерируем исключение. Проверка длины пользователя как минимум на пять символов не должна происходить на этом уровне. Можно смело предположить, что такие ограничения были введены на более высоких уровнях.

С другой стороны, сравнение двух паролей является предметом обсуждения. Например, если мы просто зашифруем и сохраним пароль рядом с пользователем в базе данных, мы могли бы снять чек и предположить, что предыдущие уровни удостоверились, что пароли равны. Однако, если мы создадим реального пользователя в операционной системе с помощью API или инструмента CLI, для которого фактически требуется имя пользователя, пароль и подтверждение пароля, мы можем захотеть взять вторую запись также и отправить ее в инструмент CLI. Пусть он повторно проверит, если пароли совпадают, и будет готов выдать исключение, если они не совпадают. Таким образом, мы смоделировали нашу бизнес-логику, чтобы соответствовать поведению реальной операционной системы.

Бросать исключения из PHP

Бросать исключения из PHP очень легко. Давайте создадим наш класс управления доступом пользователей и продемонстрируем, как реализовать функциональность добавления пользователей.

class UserControlTest extends PHPUnit_Framework_TestCase {

function testBehavior() {

$this->assertTrue(true);

}

Мне всегда нравится начинать с чего-то простого, что заставляет меня двигаться вперед. Создание глупого теста – отличный способ сделать это. Это также заставляет меня думать о том, что я хочу реализовать. Тест с именем UserControlTest означает, что я подумал, что мне понадобится класс UserControl для реализации моего метода.

require_once __DIR__ .

class UserControlTest extends PHPUnit_Framework_TestCase {

/**

* @expectedException Exception

* @expectedExceptionMessage User can not be empty

function testEmptyUsernameWillThrowException() {

$userControl = new UserControl();

$userControl->add(”);

}

Следующий тест для написания – это дегенеративный случай. Мы не будем проверять конкретную длину пользователя, но мы хотим убедиться, что мы не хотим добавлять пустого пользователя. Иногда легко потерять содержимое переменной из вида в бизнес на всех этих уровнях нашего приложения. Этот код явно потерпит неудачу, потому что у нас еще нет класса.

PHP Warning: require_once([long-path-here]/Test/../UserControl.php):

failed to open stream: No such file or directory in

[long-path-here]/Test/UserControlTest.php on line 2

Давайте создадим класс и запустим наши тесты. Теперь у нас есть другая проблема.

1	PHP Fatal error: Call to undefined method UserControl::add()

Но мы также можем это исправить всего за пару секунд.

class UserControl {

public function add($username) {

}

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

1 2	1) UserControlTest::testEmptyUsernameWillThrowException Failed asserting that exception of type “Exception” is thrown.

Наконец мы можем сделать некоторое реальное кодирование.

public function add($username) {

if(!$username) {

throw new Exception();

}

Это делает ожидание прохождения исключения, но без указания сообщения, тест все равно не пройден.

1 2	1) UserControlTest::testEmptyUsernameWillThrowException Failed asserting that exception message ” contains ‘User can not be empty’.

Время написать сообщение об исключении

public function add($username) {

if(!$username) {

throw new Exception(‘User can not be empty!’);

}

Это делает наш тест успешным. Как вы можете заметить, PHPUnit проверяет, что ожидаемое сообщение об исключении содержится в фактически выданном исключении. Это полезно, потому что позволяет нам динамически создавать сообщения и проверять только стабильную часть. Типичным примером является случай, когда вы выдаваете ошибку с базовым текстом и в конце указываете причину этого исключения. Причины обычно предоставляются сторонними библиотеками или приложениями.

/**

* @expectedException Exception

* @expectedExceptionMessage Cannot add user George

function testWillNotAddAnAlreadyExistingUser() {

$command = Mockery::mock(‘SystemCommand’);

$command->shouldReceive(‘execute’)->once()->with(‘adduser George’)->andReturn(false);

$command->shouldReceive(‘getFailureMessage’)->once()->andReturn(‘User already exists on the system.’);

$userControl = new UserControl($command);

$userControl->add(‘George’);

}

Сообщения об ошибках для дублирующих пользователей позволят нам еще больше изучить конструкцию этого сообщения. Приведенный выше тест создает макет, который будет имитировать системную команду, она потерпит неудачу и по запросу вернет приятное сообщение об ошибке. Мы внедрим эту команду в класс UserControl для внутреннего использования.

class UserControl {

private $systemCommand;

public function __construct(SystemCommand $systemCommand = null) {

$this->systemCommand = $systemCommand ?

}

public function add($username) {

if (!$username) {

throw new Exception(‘User can not be empty!’);

}

class SystemCommand {

}

SystemCommand экземпляр SystemCommand было довольно легко. Мы также создали класс SystemCommand внутри нашего теста, чтобы избежать синтаксических проблем. Мы не будем это реализовывать. Его объем превышает тему этого урока. Тем не менее, у нас есть еще одно сообщение об ошибке теста.

1 2	1) UserControlTest::testWillNotAddAnAlreadyExistingUser Failed asserting that exception of type “Exception” is thrown.

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

public function add($username) {

if (!$username) {

throw new Exception(‘User can not be empty!’);

}

if(!$this->systemCommand->execute(sprintf(‘adduser %s’, $username))) {

throw new Exception(

sprintf(‘Cannot add user %s. Reason: %s’,

$username,

$this->systemCommand->getFailureMessage()

)

);

}

Теперь эти изменения в методе add() могут помочь. Мы пытаемся выполнить нашу команду в системе, несмотря ни на что, и если система говорит, что не может добавить пользователя по какой-либо причине, мы выдаем исключение. Сообщение об этом исключении будет частично жестко запрограммировано, с присоединенным именем пользователя, а затем в конце будет объединена причина из системной команды. Как видите, этот код проходит наш тест.

Пользовательские исключения

Бросать исключения в разные сообщения в большинстве случаев достаточно. Однако, когда у вас более сложная система, вам также нужно перехватывать эти исключения и предпринимать различные действия на их основе. Анализ сообщения об исключении и принятие мер исключительно для этого может привести к некоторым раздражающим проблемам. Во-первых, строки являются частью пользовательского интерфейса, презентации и имеют изменчивый характер. Логика на основе постоянно меняющихся строк приведет к кошмару управления зависимостями. Во-вторых, каждый раз вызов метода getMessage() для getMessage() исключения также является странным способом решить, что делать дальше.

Учитывая все это, создание наших собственных исключений является следующим логическим шагом.

/**

* @expectedException ExceptionCannotAddUser

* @expectedExceptionMessage Cannot add user George

function testWillNotAddAnAlreadyExistingUser() {

$command = Mockery::mock(‘SystemCommand’);

$command->shouldReceive(‘execute’)->once()->with(‘adduser George’)->andReturn(false);

$command->shouldReceive(‘getFailureMessage’)->once()->andReturn(‘User already exists on the system.’);

$userControl = new UserControl($command);

$userControl->add(‘George’);

}

Мы изменили наш тест, чтобы ожидать наше собственное исключение, ExceptionCannotAddUser . Остальная часть теста не изменилась.

class ExceptionCannotAddUser extends Exception {

public function __construct($userName, $reason) {

$message = sprintf(

‘Cannot add user %s.

$userName, $reason

);

parent::__construct($message, 13, null);

}

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

public function add($username) {

if (!$username) {

throw new Exception(‘User can not be empty!’);

}

if(!$this->systemCommand->execute(sprintf(‘adduser %s’, $username))) {

throw new ExceptionCannotAddUser($username, $this->systemCommand->getFailureMessage());

}

Бросок нашего собственного исключения – это всего лишь вопрос замены старой команды throw на новую и отправки двух параметров вместо составления сообщения. Конечно все тесты проходят.

PHPUnit 3.7.28 by Sebastian Bergmann.

Time: 18 ms, Memory: 3.00Mb

OK (2 tests, 4 assertions)

Done.

Поймать исключения в вашем MVC

Исключения должны быть обнаружены в какой-то момент, если вы не хотите, чтобы ваш пользователь видел их такими, какие они есть. Если вы используете инфраструктуру MVC, вы, вероятно, захотите перехватить исключения в контроллере или модели. После обнаружения исключения оно преобразуется в сообщение для пользователя и отображается внутри вашего представления. Распространенный способ добиться этого – создать tryAction($action) в базовом контроллере или модели вашего приложения и всегда вызывать его с текущим действием. В этом методе вы можете использовать ловкую логику и генерацию сообщений в соответствии с вашими требованиями.

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

Если вы разрабатываете библиотеку, за ваши исключения будут отвечать ваши клиенты.

Последние мысли

Вот и все. Мы прошли все слои нашего приложения. Мы проверили в JavaScript, HTML и в наших моделях. Мы выбросили и уловили исключения из нашей бизнес-логики и даже создали наши собственные пользовательские исключения. Этот подход к проверке и обработке исключений может применяться от небольших к большим проектам без каких-либо серьезных проблем. Однако, если ваша логика проверки становится очень сложной, и разные части вашего проекта используют перекрывающиеся части логики, вы можете рассмотреть возможность извлечения всех проверок, которые могут быть выполнены на определенном уровне, для службы проверки или поставщика проверки. Эти уровни могут включать, но не ограничиваться ими, валидатор JavaScript, бэкэнд-валидатор PHP, сторонний валидатор связи и так далее.

Спасибо за чтение. Хорошего дня.

Источник

Что такое валидация данных

Краткие итоги

Зачем нужна валидация данных?

Где и когда выполнять валидацию данных?

Как выполнять валидацию данных?

Тестирование валидаторов

Заключение

Валидация — Validation:

Что такое валидация данных

Проверка паролей

Реализация пользовательской проверки паролей

Проверка данных пользователя

Изменения текста ошибок проверки достоверности

Валидация и верификация — что это простыми словами?

Еще одно значение

Определение стандарта ИСО 9000:2000

Прочие определения верификации

Прочие определения валидации

Отличия на основе перевода

Отличия верификации и валидации в сравнении

Ключевые различия понятий

Примеры верификации

Примеры валидации

Фактчекинг: 5 способов проверить информацию

<img decoding="async" onError="javascript: wp_broken_images = window.wp_broken_images || function(){}; wp_broken_images(this);" src="https://disshelp.ru/blog/wp-content/uploads/2020/10/Faktcheking_-5-sposobov-proverit-informatsiyu.jpg" />

Что это такое?

Как работает фактчекинг?

Основные приемы фактчекинга, которые помогут проверить информацию на 100%

Способы проверки достоверности данных

Что такое валидация данных

Краткие итоги

Валидация на стороне сервера

Валидация с Data Annotations

Расширение ModelMetadataProvider

Валидация на клиенте и сервере. В чем разница?

Валидация в нашей админке интернет-магазина

Общая схема обработки ошибок

Валидация на клиенте

Валидация на сервере

Вывод нормального сообщения об ошибке вместо кода

Все уроки админки на vue.js

Используемые технологии и библиотеки

1. Описание задачи

2. Структура проекта

3. Validation by reflection

3.1. Goods — проверяемая модель

3.2 @ValidationErrorMsg

3.4. Reflection

4. Запуск и проверка работы валидации

Исходный код

Проверка и обработка исключений

Проверка в пользовательском интерфейсе

Проверка в JavaScript

Проверка HTML5

Проверка в моделях

Валидация в модели Laravel

Валидация в модели CakePHP

Бросая исключения из бизнес-логики

Бросать исключения из PHP

Пользовательские исключения

Поймать исключения в вашем MVC

Последние мысли