Где вы проводите свою проверку?модель, контроллер или представление
https://stackoverflow.com/questions/134388
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Где вы размещаете проверку пользовательского ввода в приложении веб-формы?
- Вид:Клиентская сторона JavaScript
- Контроллер:Язык на стороне сервера (C # ...)
- Модель:База данных (хранимые процедуры или зависимости)
Я думаю, что для каждого уровня требуется проверка:
- Ввел ли пользователь разумное значение
- являются ли даты фактическими датами, являются ли числа фактическими числами...
- Выполните все проверки в разделе 1.опять же, плюс проверка на наличие вредоносных атак (НАПРИМЕР, XSS или SQL-инъекция)
- Проверки, выполненные в разделе 1.в основном для того, чтобы избежать отключения сервера в оба конца, когда пользователь совершает ошибку.
- Поскольку они выполняются на стороне клиента на javascript, вы не можете быть уверены, что они были запущены.Повторная проверка этих значений остановит некоторые вредоносные атаки.
- Соблюдены ли зависимости (т.е.добавил ли пользователь комментарий к правильному вопросу)
- Хороший интерфейс делает их очень трудными для нарушения.Если здесь что-то поймано, значит, что-то пошло совсем не так.
[вдохновленный этот ответ]
Решение
Я проверяю на всех уровнях, но я хотел бы отметить трюк проверки, который я использую.
Я проверяю на уровне базы данных, что надлежащие ограничения вашей модели обеспечат автоматическую проверку целостности данных.
Это искусство, которое, кажется, утрачено большинством веб-программистов.
Другие советы
Проверка в модели, необязательно автоматизированные процедуры в пользовательском интерфейсе, которые извлекают подсказки из модели и улучшают работу пользователя.
Под автоматизированными процедурами я подразумеваю, что в пользовательском интерфейсе не должно быть никакого кода проверки для каждой модели.Если у вас есть библиотека методов проверки, такая как RoR (которая имеет такие методы, как validate_presence_of :username), контроллер или представление должны иметь возможность читать их и применять эквивалентные методы javascript (или любые другие удобные).
Это означает, что вам придется дублировать полную библиотеку проверки в пользовательском интерфейсе или, по крайней мере, предоставить сопоставление, если вы используете уже существующую.Но как только это будет сделано, вам не придется писать какую-либо логику проверки вне модели.
Валидация может быть выполнена на всех уровнях.
Проверка входных данных из веб-формы (все строки, приведение к соответствующим типам и т.д.) Отличается от проверки входных данных из веб-сервиса или XML-файла и т.д.У каждого из них есть свои особые случаи.Конечно, вы можете создать вспомогательный класс Validator, таким образом, экстернализировав проверку и разрешив ей совместно использоваться представлениями.
Затем у вас есть проверка уровня DAO - достаточно ли данных в модели для сохранения (для соответствия ограничениям not null и т.д.) И так далее.У вас даже могут быть ограничения проверки в базе данных (is status in ('N', 'A', 'S', 'D') и т.д.).
Это интересно.В течение самого долгого времени я выполнял всю проверку в модели, прямо над тем, что я бы назвал DAL (уровень доступа к данным).Мои модели обычно создаются по шаблону после шлюза табличных данных с DAL, предоставляющим абстракцию и низкоуровневый API.
В дополнение к TDG я бы реализовал бизнес-логику и проверки, такие как:
- Является ли имя пользователя пустым
- Имя пользователя > 30 символов
- Если запись не существует, верните ошибку
По мере усложнения моего приложения я начал понимать, что большая часть проверки может быть выполнена на стороне клиента, используя JavaScript.Поэтому я реорганизовал большую часть логики проверки в JS и очистил свои модели.
Затем я понял, что проверка на стороне сервера (не фильтрация / экранирование - что я считаю другим), вероятно, также должна выполняться на сервере и только на стороне клиента в качестве глазури на торте.
Итак, логика проверки вернулась назад, когда я снова понял, что, вероятно, существует явная разница между проверкой входных данных / утверждением и бизнес-правилами / логикой.
В принципе, если это можно сделать на стороне клиента приложения (используя JS), я считаю это проверкой входных данных ... если это ДОЛЖНО быть выполнено моделью (эта запись уже существует и т.д.?), Тогда я бы рассмотрел эту бизнес-логику.Что сбивает с толку, так это то, что они оба защищают целостность модели данных.
Если вы не проверяете длину имени пользователя, то что мешает людям создавать имя пользователя из одного символа?
Я все еще не совсем решил, куда применить эту логику дальше, я думаю, это действительно зависит от того, что вам больше нравится: тонкие контроллеры, тяжелые модели или наоборот...
Контроллеры в моем случае, как правило, гораздо больше ориентированы на приложения, тогда как модели, если они тщательно созданы, я часто могу повторно использовать в "других" проектах не только внутри компании, поэтому я предпочитаю, чтобы модели были легкими, а контроллеры - более тяжелыми.
Силы, которые движут вами в том или ином направлении, на самом деле являются личным мнением, требованиями, опытом и т.д...
Интересная тема :)
Валидация должен это должно быть сделано в контроллере - это единственное место, которое гарантирует безопасность и оперативность.
Валидация следует это должно быть сделано в режиме просмотра - это точка соприкосновения, которая обеспечит наилучший пользовательский интерфейс и избавит ваш сервер от дополнительной работы.
Валидация будет должно быть выполнено на модели - но только для определенного базового уровня проверок.Базы данных всегда должны отражать соответствующие ограничения, но неэффективно использовать это для реальной проверки, и не всегда база данных может определить допустимые входные данные с помощью простых ограничений.
Вся проверка должна выполняться по крайней мере один раз, и это должно быть на среднем уровне, будь то в ваших объектах значений (в смысле DDD, не путать с DTO) или через бизнес-объект самой сущности.Проверка на стороне клиента может выполняться для улучшения взаимодействия с пользователем.Я обычно не выполняю проверку на стороне клиента, потому что я могу просто сразу указать все неправильные элементы в форме, но это только мое личное предпочтение: Проверка базы данных может выполняться для обеспечения целостности данных на случай, если вы испортили логику на среднем уровне или что-то завершили.
Я делаю это только в представлении и контроллере, база данных применяет некоторые из них с помощью ваших типов данных и еще много чего, но я бы предпочел, чтобы это не зашло так далеко без того, чтобы я не обнаружил ошибку.
Вы в значительной степени ответили на свой собственный вопрос, однако важно знать, что вы никогда не можете доверять просмотру, хотя это самый простой способ дать обратную связь пользователю, поэтому вам нужно провести дезинфекцию по крайней мере еще на одном уровне.
Хммм, не уверен.Я бы сказал Контролер, пока не прочитал эту статью повторно:худые Контроллеры, толстые Модели
Поскольку большинство проверок зависит от бизнес-правила, я провожу проверку на бизнес-уровень как классы инструментов сторонних производителей.Существуют и другие типы проверок, такие как пользовательский ввод, в то время как это должно быть сделано в контроллере, но вы также можете инкапсулировать эти правила проверки в классы сторонних разработчиков.На самом деле, это зависит от того, что проверять.
Проверки на стороне клиента являются второстепенными, просто сделанными для создания облегченного проверка входных данных, но проверка на стороне сервера выполняется требуется всегда.Вы никогда не сможете доверять вводимым пользователем данным ;)
.NET есть хорошие элементы управления для создания проверок, но бизнес-уровень всегда требуется лучший подход к проверке данных, а этих элементов управления недостаточно для решения этой задачи.
Простая проверка входных данных в представлении.Полная валидация в модели.Причина?Если вы измените свою технологию просмотра, а проверка выполняется в представлении / контроллере, вам придется переписать свою проверку для нового представления.Это может привести к появлению ошибок.Поместите это в модель, и это будет повторно использовано всеми представлениями...
Но, как я уже сказал, простая проверка в представлении обеспечивает скорость и легкость.
