Где лучшее место в приложении для проверки? Эмпирические правила?

Question

Я делаю приложение на C # для проекта класса. Я хочу убедиться, что строка имеет одно из трех значений. Обычно в веб-приложении я выполняю проверку с использованием JavaScript на стороне клиента. Тем не менее, это в настоящее время консольное приложение. Я знаю, что я должен сделать проверку рано, но каковы хорошие правила для проверки?

Answer 1

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

Answer 2

Если вы делаете MVC, скорее всего, вы работаете с нуля, используя TDD.

Я не уверен, что это лучший способ, но то, как я это делаю ...

• Сделать мои бизнес-объекты.
• Определите некоторую структуру валидации, чтобы бизнес-объекты могли возвращать список ошибок в своем текущем состоянии и тестировать те, которые используют модульное тестирование.
• Если вы используете linq to sql, реализуйте частичный метод OnValidate () и сделайте так, чтобы он вызывал ваш mybusinessobject.geterrors (). OnValidate вызывается, когда вы выполняете db.submitchanges (), чтобы вы могли остановить сохранение неверных данных
• Теперь в ваших контроллерах, когда кто-то создает новый бизнес-объект или редактирует его, создайте объект с любыми данными, полученными от пользователя, - затем вызовите метод geterrors () и сделайте все, что угодно
• Затем проверка на стороне клиента, если вас могут арестовать

Это структура, которая описана здесь Скоттом Гатри: http://weblogs.asp.net/scottgu/archive/2008/09/02/asp-net-mvc-preview-5-and-form-posting-scenarios.aspx

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

Answer 3

Я думаю, вы должны подтвердить три раза.

1. на клиенте, 2 на сервере и 3. в базе данных с проверочным ограничением.

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

Answer 4

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

Answer 5

Мне понравилось Тимофей подхватил MVC .

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

Подтвердить таким образом, чтобы

1. Необратимое действие не выполнено с неверным вводом

2. Пользователь не теряет работу

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

4. Приложение не выйдет из строя или аварийно завершит работу

5. Нет (общий) постоянный материал никогда не остается (или просматривается) в плохом состоянии в результате обработки приложением неверных данных

6. Пользователь не разочарован в выполнении своей полезной работы в результате того, как и когда проверка выполняется

Это должно в значительной степени покрыть это.

Answer 6

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

Answer 7

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

Answer 8

Здесь много хороших ответов об общих передовых практиках ... но ваш вопрос задан как "MVC", и для этого есть только один правильный ответ.

РЕДАКТИРОВАТЬ: Ваш "вопрос" не сказал MVC, но ваши теги сделали.

MVC = контроллер представления модели

Вся бизнес-логика уходит в контроллер. Это ответ .

Другие ответы в этом посте - отличные советы, такие как «не доверяйте проверке клиента» ... и «проверяйте везде».

Answer 9

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