Проверка логических свойств

Question

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

Скажем, у нас есть метод веб-сервиса StoreNewItem (Item item), который получает дакконтракт со всеми свойствами для элемента.Мы вставим этот новый элемент в базу данных.Некоторые из свойств являются обязательными, а некоторые - логическими.

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

Если да, как обращаться с логическими свойствами?Клиент вполне может их игнорировать, и они будут храниться как ложные в БД, так как у нас нет возможности узнать, установлено ли для них значение ложь или просто проигнорировано / забыто клиентом.

Это допустимая опцияиспользовать перечисление с True, False и Empty вместо bool в качестве типа для этих обязательных свойств?Или это просто не наша проблема?

Все мысли приветствуются!

Answer 1

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

Что касается логических значений, вы можете использовать допускающие логическое значение (bool?).

Answer 2

Вместо перечислений вы можете использовать nullable boolean (bool?), Которые полностью поддерживаются веб-сервисами.

IMHO Ваша логика проверки должна быть как минимум в БД, которая может пересылать ошибку на сервисный уровень(что в свою очередь должно вызвать ошибку).Я хотел бы, чтобы он был и на уровне обслуживания, чтобы ошибка могла возникнуть до попадания в базу данных (проверка также является частью бизнес-уровня).Иметь его в интерфейсе тоже приятно, но не обязательно.

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

Answer 3

это зависит от вашего бизнес-правила.

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

void MyServiceMethod(bool CanDoIt=false,int somethingElse)

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

void MyServiceMethod(Nullable<bool> canDoItfalse,int somethingElse)

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

Answer 4

Определенно проверьте данные. Вредоносные объекты могут легко копировать ваших клиентов.