Несколько служб WCF, ссылающихся на одни и те же контракты данных

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

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

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

Ответы

Ответ 2

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

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

Ответ 3

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

SERVICE1 client = новый SERVICE1()

client.CommonLibrary.Address.,

SERVICE2 client2 = новый SERVICE2()

client2.CommonLibrary.Address.,.

Ответ 5

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

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

Ответ 6

Мы генерируем наши служебные прокси не через помощника 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 namspace (см. Значение звездочки catch).

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