Заставить веб-службу .NET использовать локальный объектный класс, а не прокси-класс
У меня есть веб-сервис, который я вызываю из приложения Windows Forms (оба .NET, оба в одном решении), и я бы хотел, чтобы мой веб-сервис возвращал настраиваемый объект из другого места в проекте - это общий объект, который они оба имеют ссылку на, поскольку он находится в третьем проекте моего решения. Когда я вызываю веб-сервис, он возвращает объект «Человек», но он находится в пространстве имен веб-сервиса и создается из прокси-класса, который сам сгенерировал. Таким образом, я не могу манипулировать им и вернуть его в свою программу, которая ожидает объект «Человек» на основе общей копии класса, а не прокси-копии из пространства имен веб-службы, и я получаю сообщение об ошибке при попытке CType для правильного типа класса.
Как заставить веб-сервис использовать локальную копию класса, а не прокси-копию? Имеет ли смысл мой вопрос в этом контексте? Если нет, я уточню.
Следует отметить, что я прибег к передаче всех параметров ByRef и использованию этих возвращаемых значений для заполнения копии объекта, который я создаю по возвращении. Это не лучший способ сделать это!
Ответы 3
Я не уверен, но когда вы компилируете веб-службу .NET, она создает файл DLL, который вы можете попробовать использовать для локального. Но когда я создаю сервис-ориентированные приложения, я создаю различные уровни в своем решении, например, для уровня доступа к данным, логического уровня, сервисного уровня, уровня пользовательского интерфейса, уровня контроллера, и, например, на уровне контроллера я буду использовать метод аутентификации пользователя, который связан с уровнем доступа к данным и логическим уровнем, а затем я вызову этот метод на уровне обслуживания, и я также могу вызвать его на уровне пользовательского интерфейса, и если я вызываю его из уровня пользовательского интерфейса, он вызывается локально, когда я хочу его использовать на уровне сервиса я создам веб-метод, использующий этот метод, который вернет логическое значение или имя пользователя и т. д.
Если вы используете svcutil.exe для создания прокси-сервера WCF, вы можете использовать / reference в командной строке, чтобы указать сборку, содержащую общий класс. Svcutil следует повторно использовать это определение класса вместо создания нового в пространстве имен прокси службы.
Кроме того, это будет работать только в том случае, если ваш общий класс является сериализуемым и передается по значению (т.е. он отображается как контракт данных, а не как контракт службы).
Это отличается от добавления ссылки через сам проект? Мой общий класс указан в разделе «Ссылки». Думаю, я попробую это - здорово, если это сработает и указывает на вас!
Если вы используете WCF, довольно легко использовать одни и те же контракты данных и интерфейс службы между клиентом и потребителем. Вы можете либо скомпилировать сгенерированный прокси-класс и изменить его для использования правильных пространств имен, либо использовать класс ChannelFactory, чтобы создать для вас динамический прокси.
Первое решение очень хрупкое и заставит вас изменять прокси-класс каждый раз, когда изменяется интерфейс службы. Второй метод работает довольно хорошо, и мы использовали его в предыдущем проекте, над которым я работал. С помощью любого из этих методов вам необходимо убедиться, что все ваши абоненты продолжают использовать последнюю версию интерфейса.
Судя по тому, как вы описываете проблему, похоже, что вы хотите, чтобы служба и клиент использовали один и тот же экземпляр. Поскольку WCF сериализует и десериализует ваши типы при их отправке в службу и обратно, вам придется сделать что-то более умное. Вы это имели в виду?