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

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

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

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

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

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

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

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

Ответов (3)

Решение

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

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

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

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

Вот (очень) хороший урок по этой теме:

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