Где вы проводите проверку? модель, контроллер или просмотр

Где вы помещаете проверку ввода пользователя в приложении веб-формы?

  • Вид: клиентская сторона JavaScript
  • Контроллер: язык на стороне сервера (С#...)
  • Модель: база данных (хранимые процедуры или зависимости)

Я думаю, что на каждом уровне требуется подтверждение:

  • Пользователь вводил значение разумного значения
    • - даты фактических дат, цифры действительные числа...
  • Выполняйте все проверки в 1. снова плюс проверки на наличие вредоносных атак (IE XSS или SQL-инъекция)
    • Проверки, сделанные в 1., главным образом, чтобы избежать взаимной поездки сервера, когда пользователь совершает ошибку.
    • Поскольку они выполняются на стороне клиента в javascript, вы не можете доверять их запуску. Повторная проверка этих значений приведет к остановке некоторых вредоносных атак.
  • Соответствуют ли зависимости (т.е. добавил ли пользователь комментарий к действительному вопросу)
    • Хороший интерфейс очень сильно нарушает их. Если что-то поймано здесь, что-то пошло не так.

[вдохновлен этим ответом]

ОТВЕТЫ

Ответ 1

Я проверяю все уровни, но я хотел бы отметить трюк проверки, который я использую.

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

Это искусство, которое кажется потерянным для большинства веб-программистов.

Ответ 2

Проверка может выполняться на всех уровнях.

Проверка ввода из веб-формы (все строки, литье в соответствующие типы и т.д.) отличается от проверки ввода из веб-службы или XML файла и т.д. Каждый из них имеет свои особые случаи. Разумеется, вы можете создать класс помощника Validator, тем самым вытесняя проверку и позволяя ей совместно использовать представления.

Затем у вас есть проверка уровня DAO - есть ли достаточное количество данных в модели для сохранения (чтобы встретить ненулевые ограничения и т.д.) и так далее. Вы можете даже иметь контрольные ограничения в базе данных (это статус в ( "N", "A", "S", "D" ) и т.д.).

Ответ 3

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

В автоматизированных подпрограммах я подразумеваю, что в пользовательском интерфейсе не должно быть кода проверки подлинности для каждой модели. Если у вас есть библиотека методов проверки, например RoR (которая имеет такие методы, как validates_presence_of: username), контроллер или представление должны иметь возможность читать их и применять эквивалентные методы javascript (или что-то удобное).

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

Ответ 4

Это интересно. В течение самого долгого времени я выполнил всю проверку в модели, прямо над тем, что я бы рассмотрел DAL (уровень доступа к данным). Мои модели обычно имеют шаблон после шлюза данных таблицы с DAL, предоставляющим абстракцию и API низкого уровня.

В стороне TDG я бы выполнил бизнес-логику и проверки, например:

  • Пустое имя пользователя
  • Имя пользователя > 30 символов
  • Если запись не существует, обратная ошибка

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

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

Итак, назад логика проверки прошла, когда я снова понял, что, вероятно, существует явная разница между проверкой/утверждением INPUT и бизнес-правилами/логикой.

В принципе, если это можно сделать на клиентской стороне приложения (с использованием JS), я считаю это проверкой INPUT... если она ДОЛЖНА выполняться моделью (эта запись уже существует и т.д.?), тогда я рассмотрит эту бизнес-логику. Что сбивает с толку, они оба защищают целостность модели данных.

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

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

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

Какие силы приводят вас в любом направлении - это личное мнение, требования, опыт и т.д.

Интересный предмет:)

Ответ 5

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

Валидация должна выполняться в представлении - это точка соприкосновения и обеспечит лучшее UE и сохранит дополнительную работу вашего сервера.

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

Ответ 6

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

Ответ 7

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

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

Ответ 9

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

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

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

Ответ 10

Простая проверка ввода в представлении. Полная проверка в модели. Причина? Если вы измените технологию просмотра, а проверка находится в представлении/контроллере, вы должны переписать свою проверку для нового представления. Это может привести к ошибкам. Поместите его в модель, и это будет повторно использовано всеми видами...

Но, как я уже сказал, простая проверка в представлении для скорости и легкости.