C #: Webservice меняет ожидаемый тип параметра (с обычного POCO на автоматически сгенерированный класс) - PullRequest
Новая
       7

C #: Webservice меняет ожидаемый тип параметра (с обычного POCO на автоматически сгенерированный класс)

2 голосов
/ 11 апреля 2009

У меня есть следующий класс в библиотеке классов: Artist, который является POCO

Теперь у меня есть метод в веб-сервисе (который имеет ссылку на упомянутую библиотеку) с такой подписью: 

[WebMethod]
public int Artist_AddArtist(Artist a) {
 //
}

Когда я пытаюсь использовать эту службу из приложения (которое также имеет ссылку на упомянутую выше библиотеку классов), ожидаемый параметр метода Artist_AddArtist - это не Artist, а новый тип Artist это генерируется в Reference.cs, который является частичным классом, который генерируется автоматически.

Таким образом, поскольку в моем приложении я использую предположительно тот же класс Artist из библиотеки, а теперь метод веб-службы ожидает этот новый автоматически сгенерированный тип, я не могу передать его экземпляр веб-службе.

Как я могу исправить эту проблему?

Ответы [ 2 ]

3 голосов
/ 11 апреля 2009

Возможно, вам стоит перейти на услуги WCF. Насколько я помню, со службой WCF вы можете использовать одни и те же типы на стороне сервера и клиента.

В этой статье объясняется, как перенести веб-службу ASMX в службу WCF.

2 голосов
/ 11 апреля 2009

Вы не можете и не должны исправлять проблему.

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

То, что вы видите, это дизайн. См. Основы: как работают веб-сервисы .

Вкратце, когда вы используете «Добавить веб-ссылку», Visual Studio загружает файл WSDL из службы и использует схемы XML из WSDL для создания некоторых прокси-классов для представления XML, описанного схемой. Он также создает прокси-класс для самой службы, имеющий методы для каждой операции в службе.

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

Одним из способов решения этой проблемы является то, что эта проблема возникает только потому, что и клиент, и служба являются .NET. Если бы ваш клиент был написан на Java, вы бы не думали о совместном использовании классов.

Обратите внимание, что WCF может сделать это, если это необходимо. Он вводит зависимость между клиентом и службой (они оба должны использовать совместимые версии сборки, содержащие классы), но когда вам нужно это сделать, опция есть. Это полезно, когда в этих классах есть поведение, которое должно использоваться как клиентом, так и службой.

...