Где лучшее место в приложении для проверки? Эмпирические правила?
Я делаю приложение C# для проекта класса. Я хочу убедиться, что строка имеет одно из трех значений. Обычно в веб-приложении я выполняю проверку с использованием JavaScript на стороне клиента. Тем не менее, это в настоящее время консольное приложение. Я знаю, что я должен сделать проверку рано, но каковы хорошие правила для проверки?
9 ответов
Каждый модуль должен выполнять свою собственную проверку и никогда не доверять тому, что ему дает вызывающий код. Обычно это означает, что проверка должна происходить на каждом уровне вашего приложения. Особенно вы не хотите доверять какой-либо проверке на стороне клиента, потому что это может привести к дырам в безопасности. Известно, что код, работающий на клиенте, время от времени меняется.
Если вы делаете 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
Мне это нравится, и это означает, что вы можете определить свои бизнес-правила один раз и повторно использовать их на разных уровнях, что означает, что менее вероятно, что вы пропустите их в определенной области при обновлении вещей
Как вы уже сказали, вы должны проверять как можно раньше, но в клиент-серверных приложениях важно как можно быстрее проверять данные на сервере, чтобы избежать проблем с безопасностью, которые могут возникнуть.
Я думаю, что вы должны подтвердить три раза.
- в клиенте, 2 на сервере и 3. в базе данных с проверочным ограничением.
В консольном приложении вы можете проверить сразу, потому что вы знаете, в каком порядке пользователь будет вводить данные.
Мне нравится проверять, когда пользователь нажимает Ok или Next - прежде чем покинуть экран, на котором он находится. Проверка во время изменения редко срабатывает - пользователь должен иметь возможность вернуться назад, вставить строку при ее вводе, а при копировании / вставке в поле строки возникают свои проблемы. Если строка окрашена в красный цвет до тех пор, пока она не станет действительной, это может помочь, но вы все равно должны предотвратить продолжение, пока она не будет исправлена. Точно так же для того, чтобы оставить текстовое поле, может быть неприятно иметь окна сообщения, появляющиеся, делая ввод данных. Подождите, пока пользователь не скажет, что все сделано, и выполните всю проверку сразу.
Мне понравилось, что Тимоти подхватил MVC.
Поскольку нам очень мало рассказывается о характере приложения, я хочу указать некоторые общие практические правила вместе с уже предоставленными полезными советами.
Проверить таким образом, чтобы
Необратимое действие не выполняется с неверным вводом
Пользователь не теряет работу
Действия пользователя никогда не переводятся в состояние, когда ошибочный ввод не может быть легко идентифицирован и просто отозван
Приложение не выйдет из строя или вылетит
Нет (общий) постоянный материал никогда не остается (или просматривается) в плохом состоянии в результате обработки приложением неверных данных
Пользователь не разочаровывается в выполнении своей полезной работы в результате того, как и когда выполняется проверка
Это должно в значительной степени покрыть это.
Здесь есть много хороших ответов об общих передовых практиках... но ваш вопрос задан как "MVC", и для этого есть только один правильный ответ.
РЕДАКТИРОВАТЬ: ваш "вопрос" не сказал MVC, но ваши теги сделали.
MVC = Model View Controller
Вся бизнес логика идет в контроллере. Это ответ.
Другие ответы в этом посте - отличные советы, такие как "не доверяйте проверке клиента"... и "проверяйте везде".
Еще один совет: валидация везде намного проще, если вы можете определить свои правила валидации в метаинформации, которую может интерпретировать вся ваша логика валидации. Тогда вам нужно только определить правила в одном месте, и вам не нужно беспокоиться о том, что ваша клиентская проверка, проверка на стороне сервера и тестовые случаи не будут синхронизированы друг с другом.
В зависимости от того, как продвигается приложение, вы можете выполнить проверку либо перед тем, как покинуть эту страницу / шаг (если это похоже на мастер, когда вы переходите через несколько страниц / шагов), либо вы можете выполнить его проверку сразу после того, как пользователь покинет это текстовое поле / значение. Другой вариант - проверка, пока она изменена.