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

Question

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

Почему по умолчанию службы WCF хранят настройки в приложении.config?

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

1. Принцип единой ответственности - Я должен бытьвозможность добавить ссылку на библиотеку классов и перейти.Если эта библиотека классов использует ссылку на службу, эта идея снимается еще до того, как я начинаю кодировать ее.
2. Туманная конфигурация - чтобы другие библиотеки работали, мне нужно скопировать и вставитьнастройки сервиса в "основные" конфиги приложения.Если конечная точка изменяется каким-либо образом, я не могу просто беспокоиться о новой версии DLL этого класса - мне нужно беспокоиться и обо всем, что ее использует.
3. Сложные альтернативы -Программно создавать конечную точку не красиво.Период.

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

Answer 1

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

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

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

Answer 2

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

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