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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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