Unity / Spring или System.Configuration для конфигурации?

Question

Если вы уже используете Unity как часть своего проекта, есть ли смысл беспокоиться о написании традиционных классов конфигурации?

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

В прошлом, когда я использовал Spring.NET для IoC, я использовал комбинацию из двух, но мне интересно, если это сделать, просто снизить уровень согласованности в конфигурации. Конечно, если вы еще не используете библиотеки для IoC / DI, кажется излишним использовать их просто для целей настройки во время выполнения, но если вы равны , какой подход вы выберете

Answer 1

Это зависит. Конечно. : -)

Какова цель вашего файла конфигурации и, что более важно, кто является целевой аудиторией? Кто будет читать или редактировать файл конфигурации позже?

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

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

Сказав это, делать что-либо, кроме простых пар имя / значение с System.Configuration, - гигантская боль в туху. Классы конфигурации .NET содержат ошибки, серьезно недокументированы и полны странного, неожиданного поведения.

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

Я не знаю Spring, поэтому не могу ничего сказать о том, как он там работает. С Unity довольно легко смешивать и сочетать. Вы можете использовать файлы конфигурации API AND, поэтому поместите материал, необходимый для работы приложения, в вызовы API, и настраиваемый пользователем материал в файл конфигурации. Это и разделение на отдельные определения контейнеров и даже отдельные файлы конфигурации дает вам возможность отделить внутреннюю проводку от того, что администраторы должны или должны были бы коснуться.

Кроме того, в качестве последнего средства схема конфигурации Unity сама по себе является расширяемой, поэтому вы можете добавить теги в раздел конфигурации Unity. Но для этого нужно поработать с System.Configuration и , вписав их в конфигурационную среду Unity, так что это еще больше работы.

Итак, TL; DR: Здесь нет ни одного хорошего ответа. Общая схема конфигурации DI имеет преимущество в том, что она общая и уже написана. У него есть недостаток, заключающийся в том, что не обязательно очевидно, что должно быть изменено администратором, и что такое внутренняя разводка, которая может сильно испортить ситуацию. Пользовательские разделы конфигурации - это, вероятно, большая работа, которую нужно написать, но если все сделано правильно, администраторы получат четкие и очевидные моменты для редактирования, не нарушая всего здания неочевидным способом.

Answer 2

IMO, вы не должны использовать классы конфигурации, но в задачах asp.net или dot.net, специфичных для конфигурации, таких как сжатие или настройка http-модулей, потому что они не переносимы. Они требуют дополнительной работы и - в целом - не подлежат тестированию.

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

Answer 3

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

Я предпочитаю следовать подходу CMA (покрыть мой **) и помещать вещи в конфигурационные файлы xml, чтобы обеспечить гибкость обмена DLL-файлами в приложении и из него в зависимости от требований клиентов / ошибок управления!

Еще один механизм, который я использовал, - это средство поиска каталогов, которое сканирует указанный каталог на наличие DLL, а затем использует отражение, чтобы найти конкретную реализацию интерфейса. Этот интерфейс обычно имеет простой метод, такой как RegisterServices или Initialize. Пример этого есть в составном приложении WPF & Silverlight на codeplex, интерфейс для поиска - IModule.

В любом случае, я чувствую, что использование DI / IoC - лучший подход для обеспечения модульности и тестирования вашего приложения. Да, его настройка требует немного дополнительной настройки, но в первый раз вы получаете менеджера, который говорит: «Я поговорил с этим партнером, и теперь он собирается предоставить нам эту услугу, заставит ее работать» и все, что у вас есть Чтобы сделать это, напишите некоторый код, который реализует интерфейс, а затем измените DLL в файле конфигурации, вы поймете гибкость, которую он дает вам.