Предложен первоначальный вариант нового интерфейса обращения к конфигурации в Ini файле #253
Conversation
…урации в Ini файле Пока интерфейс имеет только базовую, но рабочую реализацию.
Вот этот метод не пишет новые данные в файл? Он так же используется у IniConfigurationProvider |
В одной из служб мы уже заменили nini на эту конфигурацию, работает хорошо, тоже бы хотелось на этот способ перейти во всех проектах, потихоньку уже меняем. |
Да вроде как раз, в источнике ничего не меняется aspnet/Configuration#385 |
Да в службах это отчично работает, а вот в десктоп версии нет. Так как там обычно мы не хотим заставлять пользователя в файлы ползать. |
Пока интерфейс имеет только базовую, но рабочую реализацию.
У меня нет 100% уверенности в правильность этого решения. Вообще в идеале хотелось бы перейти на конфигурации от MS IConfiguration, которая во всю используется в net. Core и доступна из нугет пакетов во фреймворке. НО она работает только на чтение. То есть изменять значения там нельзя. А при нашем использовании это очень часто надо. Но при этом в новой конфигурации все таки хочется попробовать реализовать интерфейс асбтрагированный от конкретного места хранения (ini file) и отвязанный от nini. В текущем интерфейсе IMachineConfig работа происходит напрямую с Nini. Это возможно вызовет проблемы при переводе библиотек на Core, так как по-моему в Nini не развивается совсем. Есть какой то пакет Nini в названии для нет стандарта, но на него еще надо смотреть. В идеале уйти на более универсальную конфигурацию. А место хранения ее настраивать в проекте. С другой стороны Nini передоставляет расширеный функционал по доступу к данных. Хотя не помню чтобы мы его часто использовали. В общем хочется либо услышать аргументы что это не надо и в перспективе не унифицирует доступ к различным параметрам конфигурации для модулей. Либо предложения по доработке. Например, я изначально планировал делать клон IConfiguration, но потом увидел что доступ к параметрам там проиходит через свойство Item, мне не удалось добавить индексатор на свойство Item, а делать отдельный класс аля колеекция, для реализации доступа через индексатор, тоже показалось, странных. Но может быть вы проголосуете именно за более приближенный к IConfiguration вариант. Тогда по идеи если где то массово будет использоваться оригинальный IConfiguration классы реализующие наш интерфейс смогут реализовывать и его на чтение. Давайте подумаем, вместе.