Почему пространства имен в справочнике услуг WCF относительно пространства имен по умолчанию для моего клиентского проекта WCF? - PullRequest
Новая
       16

Почему пространства имен в справочнике услуг WCF относительно пространства имен по умолчанию для моего клиентского проекта WCF?

1 голос
/ 23 марта 2010

У меня есть служба WCF с пространством имен: 

MyCompany.MyApplication.Configuration.ConfigurationHelperService

На стороне клиента у меня есть сборка, которая использует эту службу: 

MyCompany.MyApplication.Core (this is the default namespace)

Когда я добавляю службуссылка, пространство имен, которое меня просят указать в диалоге Добавить ссылку на службу , заканчивается тем, что в конце пространства имен сборки клиента добавляется: 

MyCompany.MyApplication.Core.MyCompany.MyApplication.Configuration
                                                   .ConfigurationHelperService

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

Мои вопросы:

  • Что такоеобоснование этого, это как-то связано с семантикой?
  • Должен ли я попытаться сопротивляться изменению этого поведения, изменив сгенерированный на стороне клиента источник, чтобы получить желаемое пространство имен?

IВы жили с этим в течение длительного времени (у вас та же проблема с клиентами веб-служб ASMX), но никогда не видели записанного объяснения, почему Visual Studio (и я предполагаю svcutil.exe) работает таким образом.

1 Ответ

1 голос
/ 23 марта 2010

Что ж, я думаю, у вас есть два варианта:

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

  • привыкнуть к тому факту, что если вы добавитеСсылка на службу WCF в Visual Studio, вы в основном получаете множество дубликатов - потому что если вы не контролируете оба конца связи, это действительно все, что может сделать WCF - метаданные, которыми обмениваются сервис и клиент (через WSDLили конечная точка MEX на сервисе).И поскольку это явно часть клиента, которая полностью отделена от службы (обычно все, что они разделяют, это форматы проводов, определенные в схеме XML - ничего больше), его пространство имен также будет ориентировано на клиента.Я думаю, что это (хорошая) особенность, и я бы не пытался бороться с ней .....

По умолчанию в мире SOA с использованием WCF, клиента иСервис полностью независим друг от друга.Между этими двумя объектами нет соединения с «удаленным объектом» или чего-либо подобного: клиентский прокси-сервер выполняет вызов метода, связывает эти передаваемые параметры плюс некоторую информацию о том, какой метод на сервере следует вызвать, и сериализует все это в сериализованное сообщение.(читай: текстовое / XML сообщение, в основном).Это сообщение отправляется по сети на сервер, который затем обрабатывает это сообщение и возвращает ответ.

Так что это , а не , просто вызов функции .NET или что-то - эти две части вашегоСистема (по умолчанию) абсолютно независима друг от друга.Учитывая, что, по крайней мере для меня, имеет смысл, что все, что делает клиент, будет помещено в пространства имен клиента - в конце концов, сервер может быть чем-то совершенно другим, таким как Java, PHP, мэйнфрейм IBM - у вас обычно нетлюбая подсказка, что это такое (и не нужно).

...