Я думаю, что преимущество выполнения этого в контракте на данные заключается в том, что легче модифицировать существующий контракт на данные, не нарушая совместимость со старыми клиентами.
Предположим, вы хотите вернуть дополнительную информацию вызывающей стороне.Используя контракт данных, это просто, просто добавьте дополнительное поле.Старые клиенты просто проигнорируют это.И если вы хотите, чтобы новые клиенты могли общаться со старыми серверами, просто оставьте поле необязательным.
Я бы не знал, как это сделать в контракте на обслуживание, без введения нового контракта на обслуживание или, по крайней мере,новый договор на эксплуатацию.Внедрение не будет намного сложнее, но будет более загромождать интерфейс.
Таким образом, у вас есть «гибкие» контракты на данные (возможно, со многими дополнительными полями) по сравнению с сервисными контрактами, которые перегружены избыточными операциями.1007 *
Это компромисс, но я предпочитаю «гибкий» контракт данных для большинства ситуаций.
Исключением будет, если вы контролируете и клиента, и сервер, и можете легко гарантировать, что каждый клиент будетбыть в курсе.В этом случае просто измените (и в идеале переименуйте) любой контракт, который вам нравится, и отмените поддержку старых.
Кстати: другое направление очень похоже.Вы также можете включить дополнительные (необязательные) поля в контракт данных, который клиент отправляет на сервер.Возможно, новые клиенты захотят добавить некоторые подсказки, которые могут ускорить обработку.Или добавьте дополнительные данные, которые не нужны для выполнения какой-либо операции, но которые сервер может сохранить в журнале, чтобы помочь в устранении неполадок или в любом другом случае.