Где должна быть реализована логика валидации?

Question

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

Я думаю, что есть некоторая проверка, которая ДОЛЖНА быть сделана на уровне класса, и думаю, что она, вероятно, должна храниться вместе, а не изменяться, даже если это происходит в репозитории, поэтому я стараюсь держать ее в классе.

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

Любопытно, что люди думают, и причины этого.

Answer 1

Где должна быть реализована логика проверки?

Везде.

• Вы должны выполнить проверку на уровне пользовательского интерфейса, чтобы пользователь получил немедленную полезную обратную связь (т. Е. Заполните веб-форму и рядом с ней должно быть написано javascript «слишком короткий пароль», чтобы вы не получали ненужные поездки на сервер)
• Вы должны проверить ЛЮБОЙ ввод в основное программное обеспечение из пользовательского интерфейса. Никогда не доверяйте пользовательскому интерфейсу, особенно в больших проектах или на веб-сайтах - их можно обойти или они могут быть разработаны другой командой.
• Вы должны проверить входные данные для функций / методов / классов. Они имеют присущие ограничения, которые не имеют ничего общего с требованиями проекта (кроме возможности управлять диапазоном требуемых входных данных). Идея состоит в том, чтобы поощрять безопасное повторное использование кода. Возьмите класс, и вы знаете, что он потерпит неудачу, если вы выйдете за пределы его параметров - и он скажет вам, если это так.
• Существует множество других областей, в которых должна проводиться проверка (БД, резервное копирование / восстановление, вспомогательные каналы связи и т. Д.)

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

-Adam

Answer 2

Правила проверки должны определяться на уровне класса абстрактным образом, который может 1) запускаться в собственной среде класса 2) при необходимости отображаться как правила для других зависимых сред, таких как сценарии пользовательского интерфейса или процедуры хранилища.

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

Answer 3

Контракт (интерфейс) между двумя сторонами, скажем, A и B, такой, что обе имеют определенные обязательства. Что говорится в контракте? B должен получать проверенные данные? Если это так, B не должен осуществлять проверку. Но что, если A - это пользовательский интерфейс? Очевидно, что вы не хотите помещать подтверждение там. Как правило, лучше всего представить третью сторону, скажем, C. А имеет контракт с С, который, в свою очередь, имеет контракт с Б. В ожидает подтвержденных данных. А может послать дерьмо. C выполняет проверку.

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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