Я не согласен с тем, что обходиться без объектов Request / Response - это путь.
Есть очевидные преимущества кодирования с сообщениями:
- вы можете использовать их повторно, что позволяет избежать передачи 5 целых и 3 строк множеству различных методов.
- свойства названы и поэтому могут быть надежно поняты, тогда как параметр, который передается по значению через несколько уровней, может быть перепутан и т. Д.
- они могут быть собственными объектами, а не просто контейнерами данных, если вы выберете - содержащие частные методы и т. Д.
Но вы действительно спрашиваете о версии. Не забывайте, что вы можете создавать версии сообщений в рамках контрактов на обслуживание. Классы в сборке могут иметь одно и то же имя, если они находятся в разных пространствах имен (например, v1.Request и v2.Request), и они могут реализовывать необходимый интерфейс или наследовать от некоторого базового объекта.
Они также должны быть версионированы для вашего потребителя услуг, что можно сделать с помощью пространств имен xml; Обычно я помещаю сервисные контракты (операции) в пространство имен, например http://myapp.mydomain/v1, а сообщения (объекты запроса и ответа) - в http://myapp.mydomain/v1/messages.
Одна хитрость с этим подходом состоит в том, что если у вас есть операция, назовите ее Submit в пространстве имен http://myapp.mydomain/v1, тогда по соглашению / по умолчанию мыльные объекты SubmitRequest и SubmitResponse также будут существовать в том же пространстве имен (Я не помню, что такое исключение во время выполнения, но это меня немного смутило). Решение состоит в том, чтобы поместить объекты сообщения в другое пространство имен, как я описал выше.