2010-06-24 2 views
0

У меня есть webservice с функцией, которая возвращает тип (foo). Если я использую этот веб-сервис в .NET через сгенерированные 2.0 прокси, он создает класс с именем foo в сгенерированном прокси. Если у меня есть DLL, которая содержит этот класс (foo), который является библиотекой DLL, используемой webservice, есть ли способ использовать этот класс вместо создания пользовательского прокси-класса? Я ищу что-то похожее на то, что удаляет ... но не удаляет.Использование типа webservice непосредственно через DLL

ответ

0

Я видел 3 способа сделать это:

  1. Let Visual Studio генерирует прокси-сервер, а затем изменить классы в прокси полных имен классов в библиотеке DLL, вручную. Работает, но вам придется делать это снова каждый раз, когда вы обновляете свой прокси-сервер. Плюс это действительно грязно, не так ли?
  2. Используйте общий класс/метод, который создает глубокие копии вашего прокси объектов в «реальные» объекты на отражение. Работает, но конечно с небольшой производительностью offtrade
  3. использование WCF, где вы можете ссылаться на DLL с контрактами данных (ваши классов данных) и использовать их вместо создания какого-либо прокси-сервера с помощью кода поколения.
0

Я думаю, что ключевая проблема здесь заключается в создании прокси. Я обычно использовал два разных подхода к веб-службам:

1) Традиционные сервисы, в которых вы раскрываете методы, и клиент генерирует прокси в Visual Studio, чтобы использовать методы.
2) Услуги запроса/ответа, в которых подвергаемая «услуга» является более сквозной и выполняемые «действия» инкапсулируются в объекты, отправленные и полученные от службы. Эти действия будут в той общей библиотеке, которую имеют как сервер, так и клиент.

В первом случае я часто сталкиваюсь с этой проблемой, и я действительно не думаю, что есть решение, по крайней мере, не то, что Visual Studio будет вообще нравиться. Вы могли бы вручную изменить сгенерированные прокси для использования других классов, но тогда вам придется повторять этот шаг в любое время, когда вы будете генерировать. И наоборот, вы можете создавать вне Visual Studio в чем-то вроде CodeSmith (более старая версия бесплатна, но зависит от .NET 1.1), что потребует некоторой работы по созданию шаблона для прокси и выхода за пределы среды IDE для повторного генерации в любое время, когда вам нужно их обновить.

Я могу порекомендовать хороший инструмент для последнего, и это будет проект Agatha. Он использует подход разделения «службы» от «действий», которые выполняются, и делает подход к общей библиотеке очень простым. Такая реорганизация может быть совершенно исключена из-за проекта, над которым вы работаете, в зависимости от вашего расписания, но это определенно для изучения будущих проектов.

+0

Этот проект Agatha интересен для чтения, но мне приходилось иметь дело с использованием классов RequestData и ResponseData в этом общем виде (хотя и не через веб-сервис, где это имеет больше смысла), и я должен сказать, m не является поклонником этой модели. –

0

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

+0

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

+0

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

Смежные вопросы