Несколько служб WCF, ссылающихся на одни и те же контракты данных - PullRequest
19 голосов
/ 24 февраля 2010

Я создаю набор служб WCF, которые совместно используют общие контракты данных (или объекты, если вы предпочитаете). Это простые объекты передачи данных, которые украшены атрибутами DataContract и DataMember. Я явно указываю имя и пространство имен. Пытаясь следовать принципам рекомендации IDesign, предусматривающей в среднем 12 участников на контракт на обслуживание, я разбиваю свой сервисный проект на несколько сервисов.

Мои контракты на данные находятся в отдельной сборке, которую я могу предоставить нашим клиентам, если они используют .Net. Они могут сообщить своей служебной ссылке о повторном использовании типов в сборках, на которые ссылаются. Однако, если они не используют .net и используют 2 службы, которые используют одну и ту же сущность, то, я полагаю, они получат неоднозначное справочное сообщение. Я могу видеть это в Visual Studio, если я не ссылаюсь на данные контракта DLL.

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

Ответы [ 6 ]

11 голосов
/ 28 августа 2010

Хорошая статья, которая описывает, как решить эту проблему. Совместное использование DataContracts между службами WCF

2 голосов
/ 24 февраля 2010

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

Может быть полезно знать, какую технологию они используют для использования службы, отличной от .NET? Что бросает неоднозначное справочное сообщение?

0 голосов
/ 30 мая 2012

Мы создаем наши прокси службы не через помощника Visual Studio, а с помощью пользовательских пакетных файлов, вызывающих slsvcutil.exe (поскольку мы используем Silverlight). Там вы можете указать отображение пространства имен, используя параметр / n, например:

"C:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\tools\slsvcutil.exe "^
 http://ServiceUrl/MyService.svc^
 **/n:http://youruri.org/CustomerService/DataContracts,CLR.Namespace.CustomerService^**
 /n:*,CLR.Namepsace.MyService^
 /r:"%ProgramFilesFolder%\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll"^
 /ct:System.Collections.ObjectModel.ObservableCollection`1^
 /edb^

Таким образом, все контракты данных, имеющие пространство имен http://youruri.org/CustomerService/DataContracts, генерируются в пространство имен clr CLR.Namespace.CustomerService в файле прокси и так далее. Если вы заранее сгенерировали этот прокси-сервер в той же сборке прокси, вы можете вырезать все пространство имен из вашего второго файла, и все работает отлично - мы написали небольшой инструмент для последнего шага. Все остальные пространства имен контракта будут сгенерированы в пространство имен CLR.Namepsace.MyService (см. Звездочку, означающую перехватить все)

Этот процесс требует определенных усилий, потому что вам нужно вручную обработать пакетные файлы, но как только это будет сделано, это будет хорошо.

0 голосов
/ 26 февраля 2010

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

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

0 голосов
/ 26 февраля 2010

Это зависит от того, какие инструменты они используют на стороне клиента. Например, в Axis2 для Java инструмент wsdl2java может делиться типами с помощью ключа -u.

как можно совместно использовать прокси-объекты для нескольких клиентов веб-служб Axis2?

0 голосов
/ 24 февраля 2010

У меня есть несколько служб, которые совместно используют объекты на моем конце. Я не уверен, почему у вас возникла эта проблема. В моем случае я могу получить доступ к объектам таким образом. , , ,

СЕРВИС1 клиент = новый СЕРВИС1 ()

client.CommonLibrary.Address. , ,

SERVICE2 client2 = новый SERVICE2 ()

client2.CommonLibrary.Address. , , .

...