Мы столкнулись с той же проблемой. Я тоже не нашел решения этой проблемы.
Вот две вещи, которые я видел, что люди делают (или мы сделали):
Регистрация конечной точки обслуживания вручную
Создайте реестр службы приложений, в котором говорится, как создать ChannelFactory из T. Каждый модуль может внести свой вклад в это в IModule Initialize, вызвав RegisterService<T>, и все подчиненные представления этого модуля могут получить от него свои фабрики каналов:
public interface IServiceRegistry
{
void RegisterService<T>(ServiceEndpoint ep);
ChannelFactory<T> GetService<T>();
}
Вместо возврата ChannelFactory<T> здесь вы можете просто вернуть T, конечно (предостережение emptor). View / ViewModels просто запросят IServiceRegistry в качестве зависимости и таким образом получат свои прокси службы. Это также обеспечивает удобное место для изоляции при написании модульных тестов.
Встроенная конфигурация
Система соглашений примерно выполняет те же действия, что и выше, но основана на конфигурации, встроенной в DLL (как вы предложили), и использует именованные конфигурации. Вы потребляете это так же, как описано выше, но это будет немного другой опыт. Мы используем соглашение «Endpoints.config», встроенное в нашу DLL, и читаем из него.
public interface IServiceChannelFactoryFactory //I'm terrible at naming
{
//This is much like the generated concrete class when you use "Add Service Reference"
//Except there is no method with an empty parameter
ChannelFactory<T> GetService<T>(string endpointName);
}
Наш файл «Endpoints.config» имеет несколько конечных точек на каждое имя конечной точки с добавленными атрибутами, которые делают эту конечную точку уникальной для среды (DEV, QA, Staging, Production). Я не знаю, беспокоит ли это вас, но это было удобное место для установки такого типа конфигурации.
Обе работы. Меня удивляет, что я не видел, чтобы больше людей говорили об этом. Отличный вопрос.