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

Question

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

1. Просмотр: клиентская часть JavaScript
2. Контроллер: язык на стороне сервера (C # ...)
3. Модель: База данных (хранимые процедуры или зависимости)

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

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

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

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

То, что движет вами в любом направлении, - это действительно личное мнение, требования, опыт и т. Д ...

Интересная тема:)

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

Хмммм, не уверен. Я бы сказал, что Контроллер, пока я не прочитал эту статью о: тощие контроллеры, толстые модели

http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html

Answer 10

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

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