Обработка одного и того же определения класса из нескольких веб-сервисов

Question

Ситуация:

У нас есть проект библиотеки, в котором содержится большая часть нашего кода для различных интеграций, над которыми мы работаем. Многие интеграции используют API веб-сервисов, и мой руководитель не хочет, чтобы в проект добавлялось 5 миллиардов ссылок на веб-сервисы.

Затем мы обычно добавляем ссылку на новый проект, копируем References.vb в решение и просто вызываем сгенерированный код. Не очень удобно, если в сервис вносятся изменения, но он работает.

Недавно я столкнулся с проблемой, когда мы должны использовать 3 веб-сервиса для одной и той же интеграции. 2 из них содержат одинаковые определения классов, однако они находятся в разных пространствах имен, потому что они принадлежат разным сервисам. Это стало проблемой для меня, потому что одна из служб ищет пользователя на основе идентификатора пользователя, а другая отбрасывает блоки пользователей. Оба возвращают объект или список, который в точности семантически одинаков. И мне нужно обрабатывать данные одинаково, независимо от того, пришли они из одного сервиса или другого.

Мое решение состояло в том, чтобы убрать дубликаты классов в службе и заменить их классами, унаследованными от общих базовых классов. Это позволило мне работать с обоими объектами, как если бы они были одинаковыми, однако для этого потребовалось изменить сгенерированный прокси-сервер веб-службы. Поэтому это изменение нужно будет вносить каждый раз, когда мне нужно восстановить прокси.

Мне любопытно, что вы все могли бы подумать, что лучшим решением было бы это.

Answer 1

Вы будете сожалеть о том, что играете в игры с копированием Reference.vb и редактированием сгенерированных файлов.

Переключитесь на WCF, и вы сможете сказать, что хотите повторно использовать типы, вместо того, чтобы иметь более или менее одинаковые типы.

Кстати, они были бы "менее" одинаковыми, если бы не все веб-ссылки обновлялись в одно и то же время после смены сервера.

Answer 2

wsdl.exe с помощью переключателя /sharetypes позволяет использовать одни и те же типы в нескольких определениях служб при условии, что подписи проводов неверны. Я не смог использовать его в моей ситуации, потому что различные wsdl-контракты были небрежно распределены между именами.

Answer 3

Я думаю, что вы действительно должны смотреть на WCF для 3.5+, но для .NET 2.0 посмотрите на что-то вроде WSCF (сначала контракт Web-сервисов), который определяет контракты в XML и генерирует набор библиотек, которые можно повторно использовать в разных сервисах. Например, вы определяете пространство имен MyComany.WS.Common и используете это пространство имен в нескольких проектах. Генерация кода затем создает общую библиотеку типов, которая используется во всех веб-сервисах. Мы широко используем это в наших решениях .NET 2, и это здорово. Нам пришлось проделать дополнительную работу по созданию кода, чтобы он вписался в наш процесс сборки, но как только это было сделано, мы никогда не оглядывались назад.

Со временем мы переходим на .NET 3.5, поэтому WSCF устареет

Вот ссылка на сайт thinktecture для WSCF.

Answer 4

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