Программная настройка конечных точек по сравнению с web / app.config

Question

Кто-нибудь много думал об этом? Лично я считаю, что управление конечными точками в файлах конфигурации - это боль. Есть ли плюсы / минусы, чтобы сделать одно над другим?

Answer 1

Только очки в пользу файлов конфигурации от меня.

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

Вы также можете иметь несколько экземпляров приложения, работающих с разными конечными точками.

Answer 2

Мне тоже нравится подход к конфигурации, кроме файла конфигурации, который может быть довольно большим.

Одна вещь, которую я заметил в конфигурации WCF, - это то, что вы можете делать из кода, который вы не можете делать в XML-конфигурации, не добавляя свои собственные пользовательские расширения. Другими словами, выполнение конфигурации в коде даст большую гибкость, конечно, вы также можете просто кодировать свои собственные расширения и использовать их из конфигурации.

Тем не менее, обратите внимание, что в Visual Studio есть то, что я бы назвал «ошибкой»: если вы начнете создавать свои собственные расширения и включать их в XML, то VS больше не будет любить ваш файл конфигурации и будет помечать их как ошибки, а затем, если вы попытаетесь добавить новую службу через мастера, она не сможет добавить конечную точку в конфигурацию.

---

Это своего рода продолжение моего собственного ответа:

После месяцев, проведенных в конфигурации xml, я все изменил, чтобы создать конечные точки и привязки в коде. Я нашел действительно хороший случай для того, чтобы иметь это в коде;

Если вы хотите иметь развертываемую / разделяемую .dll, содержащую клиентов WCF.

Так, например, если у вас есть CommonClients.dll, который содержит все ваши интерфейсы WCF и контракты для связи с каким-либо удаленным сервером, то вы не хотите также говорить «вот 100 строк xml, которые вы также должны отбросить в ваш app.config для каждого клиента, чтобы он работал ". Построение всего этого в коде в этом случае работает намного лучше.

Существует также «особенность» .NET 3.5, где, если у вас есть некоторые расширения wcf, вы должны указать полное имя сборки. Это означает, что если ваша сборка, содержащая расширения, изменяет номер версии, вы должны также изменить имя сборки в файле конфигурации. Предполагается, что в .NET 4 исправлено использование короткого имени сборки и полное имя не требуется.

Answer 3

От руки, конечная точка в конфигурационном файле не нуждается в перекомпиляции при изменении. Это также означает, что вам просто нужно обновить файл конфигурации при перемещении приложения из разработки в UAT в производство.

Если вы просто кодируете что-то для собственного использования дома, то никакой разницы нет. Однако в бизнес-среде определение enpoint, заданного в файле конфигурации, избавляет от всех видов головной боли.

Answer 4

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

Самое большое беспокойство по поводу простых файлов конфигурации может заключаться в том, что конечный пользователь может случайно (или специально) изменить его, что приведет к сбою приложения. Чтобы преодолеть это, вы можете сделать несколько тестов в коде, чтобы проверить правильность конфигурации в файле конфигурации, а если нет, инициализировать его программно с некоторыми значениями по умолчанию. Я представил, как вы могли бы сделать это в другом ответе на этот вопрос.

Answer 5

Обычно я делаю программную настройку, так как не хочу раскрывать внутреннюю структуру моих приложений пользователю. Единственное, что я сохраняю настраиваемым, это адрес службы, но даже это я храню в разделе userSettings, а не в system.ServiceModel.

Answer 6

При использовании app.config ваше приложение не нужно перекомпилировать, чтобы приспособиться к изменению. Также его можно повторно использовать в нескольких ситуациях с одним и тем же кодом. Наконец, жесткое кодирование ваших конечных точек (или всего, что может быть изменено) является плохой практикой кодирования. Не бойтесь файла конфигурации, это декларативное программирование. Вы говорите: «Я хочу использовать эту конечную точку». и это делает работу за вас.

Answer 7

Проверьте приложение .NET StockTrader . Он использует репозиторий для хранения данных конфигурации и имеет отдельное приложение для управления конфигурацией. Настройка и структура довольно продвинуты, и для любого, как я, есть немало проблем, у которых пока есть только основы конфигурации WCF, но я бы сказал, что стоит посмотреть.

Answer 8

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