Результаты веб-службы ASP.NET, прокси-классы и преобразование типов

Я все еще новичок в мире ASP.NET, так что я мог бы быть далеко от базы здесь, но пока это в меру моих (ограниченных) знаний!

Допустим, у меня есть стандартный бизнес-объект "Контакт" в пространстве имен Business. Я пишу веб-сервис, чтобы получить контактную информацию из базы данных и вернуть ее. Затем я пишу клиентское приложение для запроса указанных деталей.

Теперь я также создаю служебный метод, который принимает "контакт" и делает с ним магию, как, например, Utils.BuyContactNewHat(). Который, конечно, принимает контакт типа Business.Contact.

Затем я возвращаюсь в свое клиентское приложение и хочу использовать метод BuyContactNewHat, поэтому я добавляю ссылку на свое пространство имен Utils, и это так. Однако возникает проблема с:

Contact c = MyWebService.GetContact("Rob);
Utils.BuyContactNewHat(c); // << Error Here

Поскольку возвращаемый тип GetContact имеет MyWebService.Contact а не Business.Contact как ожидалось. Я понимаю, почему это происходит, потому что при доступе к веб-сервису вы фактически программируете с использованием прокси-класса, сгенерированного WSDL.

Итак, есть ли "более простой" способ справиться с этим несоответствием? Возможно, я подумывал о том, чтобы попытаться создать универсальный класс преобразователя, который использует отражение, чтобы два объекта имели одинаковую структуру, а не просто передавали значения из одного в другой.

Ответы

Ответ 1

Вы на правильном пути. Чтобы вернуть данные из прокси-объекта обратно в один из ваших собственных объектов, вам нужно сделать левый правый код. т.е. значения свойств копирования. Готов поспорить, что уже существует общий метод, который использует отражение.

Некоторые люди будут использовать что-то другое, кроме веб-службы (удаленное соединение .net), если они просто хотят получить бизнес-объект через провод. Или они будут использовать двоичную сериализацию. Я предполагаю, что вы используете веб-сервис по какой-то причине, поэтому вам придется выполнять копирование свойств.

Ответ 2

На самом деле вам не нужно использовать сгенерированный класс, который предоставляет WSDL. Если вы посмотрите на код, который он генерирует, он просто вызывает вызовы в некоторые классы .NET Framework для отправки запросов SOAP. Раньше я скопировал этот код в обычный файл .cs и отредактировал его. Хотя я не пробовал это конкретно, я не вижу причин, по которым вы не могли отказаться от определения прокси-класса и использовать исходный класс для получения результатов вызова SOAP. Он, должно быть, уже делает отражение под капотом, кажется, стыдно сделать это дважды.

Ответ 3

Я бы порекомендовал вам посмотреть на создание расширений импортеров схем, которые вы можете использовать для управления генерацией прокси-кода. Этот подход может использоваться (изящно) для решения вашей проблемы без kludges (например, копирование объектов из одного пространства имен в другое или изменение класса, сгенерированного proxy, только для его замены при следующем обновлении веб-ссылки).

Здесь (очень) хороший учебник по теме:

http://www.microsoft.com/belux/msdn/nl/community/columns/jdruyts/wsproxy.mspx