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

У меня есть веб-сервис, который я вызываю из приложения Windows Forms (оба .NET, оба в одном решении), и я бы хотел, чтобы мой веб-сервис возвращал настраиваемый объект из другого места в проекте - это общий объект, который они оба имеют ссылку на, поскольку он находится в третьем проекте моего решения. Когда я вызываю веб-сервис, он возвращает объект «Человек», но он находится в пространстве имен веб-сервиса и создается из прокси-класса, который сам сгенерировал. Таким образом, я не могу манипулировать им и вернуть его в свою программу, которая ожидает объект «Человек» на основе общей копии класса, а не прокси-копии из пространства имен веб-службы, и я получаю сообщение об ошибке при попытке CType к правильному типу класса.

Как заставить веб-сервис использовать локальную копию класса, а не прокси-копию? Имеет ли смысл мой вопрос в этом контексте? Если нет, я уточню.

Следует отметить, что я прибег к передаче всех параметров ByRef и использованию этих возвращаемых значений для заполнения копии объекта, который я создаю по возвращении. Это не лучший способ сделать это!


.net class web-services proxy-classes
person SqlRyan    schedule 19.10.2008    source источник
comment
Я уже задавал этот вопрос раньше.   -  person Richard Nienaber    schedule 20.10.2008

Ответы (3)


arrow_upward
3
arrow_downward

Если вы используете svcutil.exe для создания прокси-сервера WCF, вы можете использовать / reference в командной строке, чтобы указать сборку, содержащую общий класс. Svcutil следует повторно использовать это определение класса вместо создания нового в пространстве имен прокси службы.

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

person Franci Penov    schedule 19.10.2008
comment
Это отличается от добавления ссылки через сам проект? Мой общий класс указан в разделе "Ссылки". Думаю, я попробую это - здорово, если это сработает и указывает на вас! - person SqlRyan; 21.10.2008

arrow_upward
2
arrow_downward

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

Первое решение очень хрупкое и заставит вас изменять класс прокси каждый раз при изменении интерфейса службы. Второй метод работает довольно хорошо, и мы использовали его в предыдущем проекте, над которым я работал. С помощью любого из этих методов вам необходимо убедиться, что все ваши вызывающие абоненты продолжают использовать последнюю версию интерфейса.

Судя по тому, как вы описываете проблему, похоже, что вы хотите, чтобы служба и клиент использовали один и тот же экземпляр. Поскольку WCF сериализует и десериализует ваши типы при их отправке в службу и обратно, вам придется сделать что-то более умное. Вы это имели в виду?

person smaclell    schedule 19.10.2008

arrow_upward
0
arrow_downward

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

person milot    schedule 19.10.2008