WCF сервис должен предоставить интерфейс, где методы разделены на группы, например:

MySystem.File.Export()
MySystem.File.Import()
MySystem.Application.CreateNew()
MySystem.Application.Save()
MySystem.Definitions.GetLookup()

Kaк правильно все это организовать?

Понятие Namespace в WCF (суть XML) и в .NET — это сильно разные вещи и одно на другое в общем случае не мапится.
Правильно выделить все родственные операции в один контракт и использовать этот контракт не заморачиваясь на пространства имен.
Еще можно насоздавать кучу проксиков, указав для каждого пространство имен, понимая при этом что каждый из проксиков — это отдельное в общем-то подключение.
Либо объявить все эти интерфейсы в своей сборке, помещая каждый из них в нужное пространство имен, а клиентов делать через ChanellFactory.
Либо посмотреть сгенерированного клиента и руками растащить интерфейсы по разным пространствам имен.
А зачем вам такой, извините, изврат понадобился?

Здравствуйте, RushDevion, Вы писали:

RD>Понятие Namespace в WCF (суть XML) и в .NET — это сильно разные вещи и одно на другое в общем случае не мапится.
RD>Правильно выделить все родственные операции в один контракт и использовать этот контракт не заморачиваясь на пространства имен.
RD>Еще можно насоздавать кучу проксиков, указав для каждого пространство имен, понимая при этом что каждый из проксиков — это отдельное в общем-то подключение.
RD>Либо объявить все эти интерфейсы в своей сборке, помещая каждый из них в нужное пространство имен, а клиентов делать через ChanellFactory.
RD>Либо посмотреть сгенерированного клиента и руками растащить интерфейсы по разным пространствам имен.
RD>А зачем вам такой, извините, изврат понадобился?


пространство имен само по себе конечно не принципиально, просто мы только начали проект с WCF и я пытаюсь понять как мне там группировать методы. Если можно растащить родственные операции по разным контрактам — замечательно, но как это сделать? На каждый контракт создавать по сервису? Или как-то можно заставить все это работать внутри одного сервиса?

У меня слишком мало информации о ваших задачах, чтобы давать какие-то конкретные рекомендации.
Судя по гранулярности ваших операций, они не слишком подходят для клиент-серверной архитектуры.
Это скорее похоже на сервисы в рамках одного процесса.
Тогда зачем используется WCF? Не проще будет делать интерфейсы и инджектить реализации через DI?
Если все таки WCF, то рекомендую найти вот такую книгу.
Конкретно — глава 2 (про котракты служб и сцепление на стороне клиента), плюс там же в первой главе есть пример InProcFactory — возможно это то, что вам подойдет.


> Если можно растащить родственные операции по разным контрактам — замечательно, но как это сделать? На каждый контракт создавать по сервису? Или > > как-то можно заставить все это работать внутри одного сервиса?

Можно и так и так. Контракт-по сути всего лишь интерфейс.
Вы можете имплементить интерфейсы в одном классе, можете заводить по отдельному классу на каждый интерфейс — это дело вкуса.
В конечном счете все сведется к выставлению Endpoints для SeviceHost (одного или нескольких).