Где вы делаете проверку в веб-приложении (бэкэнд)?

Question

Где вы проводите проверку в веб-приложении (бэкэнде)?

Вариант № 1: Сервисный уровень?

UserService.validate(FORM);  // verify and returns struct of errors

Вариант № 2: Слой объекта, на сеттер? например,

user.setEmail(email);    // throws invalid/used e-mail

Вариант № 3: Уровень объекта, validate ()? например

user.init(FORM);    // accept any values, no type checking
user.validate();    // returns struct of errors

Что вы берете? Спасибо!

Answer 1

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

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

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

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

Надеюсь, это поможет.

Answer 2

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

Я думаю, что фреймворки, такие как Transfer, побуждают вас поддерживать валидацию объектов внутри объектов, тогда как механизмы / фреймворки, такие как Validat Alegad , предназначены для того, чтобы валидация не проводилась. Я не думаю, что любой из этих подходов неправильный, на самом деле это просто вопрос того, что вы предпочитаете (и что подходит для приложения).

Тем не менее, из трех вариантов вариант № 2 - это неправильное использование обработки исключений для ситуаций, в которых вы ожидали результатов. Имея метод validate (будь то на объекте или в сервисе), вы можете управлять ошибочными ситуациями проверки более изящно, чем перехватывать исключения и пузырить их пассивно (захватывать и возвращать структуру с информацией о сбое) или явно (перебрасывать и т. д.)

Answer 3

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

Answer 4

Прежде всего, +1 от меня за jborque.

Я хотел бы добавить, что проверки типа ввода очень повторяющиеся, например

Пользовательский интерфейс: не допускайте, чтобы имя было длиннее 30 символов BIZ: создать исключение / создать нарушенное правило, если имя длиннее 30 символов DB: сделать имя столбца шириной 30 символов UNIT TEST: имена тестов <30,> 30, ровно 30 символов

Это БОЛЬШОЙ кандидат на генерацию кода. Если 30 внезапно изменится на 40 и вы используете генерацию кода, сделать это изменение так же просто, как перезапустить генератор кода (и создать сценарии обновления БД для любых производственных данных).

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