Что отправить обратно при удалении dto из списка

Question

У меня сервис-ориентированная архитектура. Клиент содержит список родительских и дочерних dtos, которые связаны с внешним интерфейсом. Сервис для этого является get, который возвращает полный список всего.

При удалении лучше:

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

Заранее спасибо

Answer 1

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

Для операции удаления это довольно просто реализовать: просто запустить и забыть.

Блог Уди Даана - хорошее место, чтобы узнать о реальной ориентации на услуги.

Если вы хотите остаться с шаблоном обмена сообщениями RPC, подразумеваемым вашим вопросом, я все равно скажу, что метод должен вернуть void . Если вы получите пустой ответ из синхронного HTTP POST, это будет означать успех, в противном случае вы получите ошибку SOAP или другой результат ошибки.

Answer 2

Это на самом деле зависит от бизнес-кейса.

Когда два пользователя используют систему. Оба добавляют и удаляют элементы из списка.

Когда пользователь A удаляет и элемент, вы хотите, чтобы он видел изменения от пользователя B, или требуется, чтобы пользователь A нажимал обновление, чтобы увидеть эти изменения?

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

Answer 3

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

Answer 4

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

В этом случае это, вероятно, означало бы, что служба не будет знать о существовании клиента и его реализации, так что это исключит службу, непосредственно манипулирующую списком клиентов. Если эта служба реализована в виде библиотеки классов, я бы порекомендовал подход «издатель / подписчик», где служба предоставляет событие C # типа, содержащего соответствующую информацию об удалении, а клиент обрабатывает это событие и соответственно обновляет свой список.

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