Подтверждение субъекта самопроверки (EF) через WCF

Question

У меня проблемы с определением того, каким должен быть мой OperationContract при добавлении / обновлении объекта. Я хочу отправить сущность (или список сущностей) на ObjectContext через Службу WCF (которая создаст экземпляр Бизнес-менеджера для меня для выполнения фактической проверки).

Если сущность проходит все правила валидации (для которых вполне может потребоваться запрос базы данных для определения прохождения / сбоя для более сложных бизнес-правил), она будет сохранена в базе данных, и мне нужно будет иметь возможность передать обратно свой идентификатор (первичный ключ Identity Column) и значение токена параллелизма (столбец timestamp), но в случае его сбоя, очевидно, мы хотим получить сообщение или сообщения о том, что было не так. В случае обновления все, что нам понадобится, - это новое значение токена параллелизма, но опять-таки нам нужны сообщения о проверке.

Чтобы сделать это более сложным, у сущности может быть также несколько дочерних / внучатых сущностей. Например, у Поездки будут Остановки, которые потенциально могут иметь Ордера.

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

[OperationContract]
bool AddEntity(Entity e);

[OperationContract]
bool UpdateEntity(Entity e);

У кого-нибудь есть отличные идеи для этого? Наверное, я просто ищу здесь практический совет.

Должны ли мы пытаться сохранить коллекцию объектов в одном вызове службы?

Должны ли мы передавать сообщения проверки через договор о сбое?

Любой совет / вклад будет полезен, спасибо!

Answer 1

Должны ли мы пытаться спасти коллекция объектов в одном сервисе звоните

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

Должны ли мы передавать подтверждение сообщения по вине контракта?

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

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

Одно небольшое замечание для STE: передача только идентификаторов и временных меток может быть сложной. Я не уверен, что вам не нужно отключать отслеживание, когда вы хотите установить их, и после этого снова включить отслеживание.