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

Question

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

Мне нравится проверять после того, как пользователь нажимает кнопку «ОК» или «Далее» - прежде чем они покинут экран, они включены. Проверка во время модификации редко работает - пользователь должен иметь возможность backspace, вставлять строку при вводе в нее, а копирование/вставка в поле строки имеет свои собственные проблемы. Если строка окрашена в красный цвет до тех пор, пока она не будет действительной, это может помочь, но вам все равно нужно предотвратить продолжение до тех пор, пока оно не будет исправлено. Аналогично, для выхода из текстового поля может возникнуть раздражение при появлении сообщений при вводе данных. Подождите, пока пользователь скажет, что все сделано, и выполните всю проверку сразу.

Answer 5

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

EDIT: Ваш «вопрос» не сказал MVC, но ваши тэги сделали.

MVC = Model View Controller

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

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

Answer 8

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

Answer 9

Мне понравилось Timothy's picking up on MVC.

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

Validate таким образом, что

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

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

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

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

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

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

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