Где проверить пользовательский ввод в программе?

Question

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

Я вижу 3 варианта:

1. Моей первой идеей было поместить проверочный код прямо на уровне домена. Но я чувствую, что тогда у меня может возникнуть соблазн провести проверку класса A, затем ту же проверку B, которая использует A, затем C, которая использует B, и т. Д. Это, с другой стороны, хорошо, так как легко проверить логику проверки.

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

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

Как вы вообще подходите к этой проблеме?

Answer 1

Как вы заметили, существует более одного места для проверки данных.

Существует также несколько уровней проверки:

1. Правильный формат и тип;присутствуют все обязательные значения (например, если требуется дата рождения, убедитесь, что она отображается и имеет тип Date; если это строка, убедитесь, что она соответствует ожидаемому формату, например «yyyy-MM-dd»)
2. Уровень 1 плюс «корректность бизнеса»: завершенная транзакция действительна в соответствии с вашими бизнес-правилами (например, «дата рождения должна быть как минимум на восемнадцать лет раньше, чем сегодня»).

Есть школаМысль, которая говорит, что вы должны рассмотреть все из них:

1. Проверка на клиенте, чтобы обеспечить лучший опыт для пользователей.Не заставляйте их ждать поездки туда и обратно, чтобы узнать, что что-то не так.Поставьте на место валидацию JavaScript, которая сразу же сообщит им валидность уровня 1.
2. Повторная проверка на стороне сервера, потому что ваш сервисный уровень может не иметь пользовательского интерфейса перед ним.Свяжите и проверьте все значения, входящие в ваш уровень обслуживания.
3. Выполните все проверки уровня 2 как часть транзакции на уровне обслуживания.Убедитесь, что входные данные верны с точки зрения бизнеса.
4. Если база данных используется несколькими приложениями, поместите бизнес-логику в ограничения, хранимые процедуры и триггеры для обеспечения целостности данных.

Я не думаю, что это должны быть решения «или» или «*».

Answer 2

Не перепутайте «когда» и «где».

«Когда» должно быть как можно раньше, может быть вызвано слоем предварительной установки.

«Где» должно быть близкок доменной логике.

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

Answer 3

Вам часто нужно выполнить оценку на нескольких уровнях:

• Уровень клиента, чтобы гарантировать, что пользовательский опыт настолько хорош, насколько это возможно.Например, избегая ввода 10-ти полей и необходимости повторного запуска из-за неправильного ввода.
• На уровне службы, поскольку вы не уверены на 100%, что запрос был обработан клиентом (возможно, некоторыеодин отправил сообщение непосредственно на уровень обслуживания.
• На уровне обслуживания, потому что некоторые вещи нельзя проверить на клиенте.

Хорошая новость заключается в том, что некоторые технологии позволяют вамукажите правила проверки один раз, и они сгенерируют код проверки как для клиента, так и для сервера. См. http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx Это помогает в первых двух случаях выше.