Список <Customer>все или ничего

Question

Я создаю веб-сервис с использованием Windows Communication Foundation (WCF), и в настоящее время я не знаю, каков наилучший способ его проверки.

У меня есть два метода: CreateCustomer(Customer) и CreateCustomers(List<Customer>).

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

Или я должен разрешить им только вызывать метод CreateCustomer(Customer) и заставлять их повторно вызывать его, если они хотят создать более одного клиента?

Answer 1

В такой ситуации я бы порекомендовал подход, подобный транзакции.

По сути, вы бы проверили все, если они не пройдут, не сгенерируют исключение или другие неудачные события проверки, с клиентами, которые не прошли, используя идентификатор или фактические объекты. Это позволит человеку на другой стороне конвейера определить проблемы.

Для сохранения в базе данных я хотел бы изучить это и в транзакции, частично спасая 1-7 клиентов, но не 8-й может вызвать проблемы.

Answer 2

Поскольку вы разрабатываете веб-сервис, вы, вероятно, захотите сократить количество поездок в оба конца. Это говорит о том, что избавление от CreateCustomers (список) является плохой идеей.

Теперь трудная часть. Я бы предложил, чтобы вы предоставили клиенту возможность обрабатывать ошибки. Вы можете изменить сигнатуру метода CreateCustomers, чтобы включить bool в отношении того, хотят ли они все или ничего. Примерно так: CreateCustomers (список, все или ничего). Тип возвращаемого значения для этой операции должен быть списком объектов со свойством для клиента и логическим значением того, был ли он успешным.

Answer 3

В описанном вами сценарии все сводится к тому, как вы хотите управлять ошибками (faultcontract) в своем WCF.

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

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

Answer 4

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

Принятие клиентов, которые являются действительными, а те, которые не являются, может даже запутать вопросы, как в этой ситуации:

Я делаю список котлет ...; размером 100 и позвоните вашим CreateCustomers (Кастс). 20 плохо, но вы предоставляете информацию о том, почему. Оказывается, мой клерк ввода данных много опечаток. Проблема решена, я повторяю попытку CreateCustomers (custs), но я получаю сообщение об ошибке, что 80 из них уже существуют. Вы все еще создали 20, которые были исправлены (потому что вы сделали это в прошлый раз, когда я передавал данные)?

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

Answer 5

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