Почему клиенты WCF зависят от файла app.config?

Question

Как много вещей, я уверен, что есть хорошая причина для этого, поэтому, пожалуйста, помогите мне понять ...

Почему по умолчанию сделать настройки службы WCF магазина в app.config?

Это было так расстраивать, пытаясь работать с несколькими библиотеками классов Silverlight. Эти библиотеки классов должны быть полностью независимы друг от друга, и эта зависимость от app.config, кажется, вызывает следующие головные боли:

1. Single Принцип ответственности - я должен иметь возможность добавить ссылку к класс библиотеки и идти. Если эта библиотека классов использует ссылку на службу, эта идея снимается до того, как я даже начну кодирование против нее.
2. Конфигурация Muddy - Чтобы заставить другие библиотеки работать, мне нужно скопировать и вставить конфигурацию сервисов в «основные» конфигурации приложений. Если конечная точка изменяется каким-либо образом, я не могу просто беспокоиться о новой версии DLL этого класса - мне тоже нужно беспокоиться о том, что ее использует.
3. Комплексные альтернативы - Программируемое создание конечной точки не очень красиво. Период.

Должен быть лучший способ. Почему WCF не разделяет конфигурацию службы на ServiceName.config или что-то, что копируется в выходной каталог. Что мне не хватает? Как вы справляетесь с этим?

Answer 1

Потому что альтернативы тоже не очень хороши. Проблема с «ServiceName.config» заключается в том, что ServiceName также необходимо настраивать.

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

Answer 2

Я согласен с @Henk - сборники библиотек не должны иметь ссылок WCF. Если по какой-то причине это требует одного, я бы использовал инъекцию зависимостей и передал справочную службу в библиотечную функцию - , это жизненно важно для максимального преимущества тестирования.

Я также не покупаю ваш аргумент «Программировать создание конечной точки не очень». Создание и назначение конечной точки - это всего лишь пара строк кода, и это метод, который я использую почти исключительно с моими компонентами Silverlight (например, если в файле ServiceReferences.ClientConfig не указан адрес, я возвращаюсь в известные места службы внутри хостинг-приложения, и в этом случае эти конечные точки программно создаются).

В принципе, если вы не против пары строк кода, необходимых для программного создания конечной точки, то вы можете хранить данные своего адреса где угодно, в любом файле конфигурации. Вам нужно только сохранить адреса в app.config, если вы собираетесь использовать чисто декларативный подход.