Разработки          Услуги          О компании          Контакты  

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

Описание применения UniConfig

Материал из биософт-м

Перейти к: навигация, поиск

  !   Данная информация предназначена только только для IT-специалистов по системной интеграции модулей БИОСОФТ-М. (см. Руководства пользователя к программным продуктам)

Унифицированная централизованно-локализованная, схема хранения конфига приложений: (детали - 1п)

Все что нужно есть в заготовке проекта где объявлено:

    // Global module config data controller
    //   (always exists as this single instance)
    ref<CAbsexGlobalConfigIface> x_rAbsexGlobalConfig;
    ref<CAbsexGlobalConfigIface> x_rAbsexGlobalConfig_Get();

И две функции необходимые для колбака на создание индивидуального конфига модуля и типизации ссылки.

Каждый модуль имеет пакет UniConfig объект которого регистрируется в глобальном конфиге приложения автоматически.

(Весь старый лохматый код регистрации конфига убран из заготовки проекта и унифицирован в библиотеках)

На низком уровне

1) Существует глобальная-в-процессе карта всех локальных конфигов в CAppProcessIfaceGp::GGetThisAppProcess()->x_rConfigHookMap

2) CProject регистрирует своей конфиг в глобальной карте под уникальным именем.

    // Register it in the process-global map
    ref<CConfigHookIfaceGp> rRegisteredGlobalConfig =
        CAppProcessIfaceGp::GGetThisAppProcess()->
            x_rConfigHookMap->
                MapSingleConfigHookInstance(
                    "Absex", // our unique config key
                    rAbsexGlobalConfig);

3) При регистрации модуль создает объект своего конфига по умолчанию, но далее использует тот объект который вернет глобальная карта.

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

4) Для хранения и управления отдельной единицей конфига (теперь по одной для каждого модуля) библиотека наследует CConfigHookIfaceGp и

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

6) Техническая деталь: все конфиги хранятся в глобальной карте в виде unidef.

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

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

7.1) Важно локализовать доступ к глобальному объекту конфига чтобы не повредить тестам и проч.

По этому появился Отдельный временный конфиг для тестов

8) Конфиги из этой карты все сохраняются UV в глобальном файле конфига, каждый конфиг под своим уникальным ключем.

9) Конфиг проекта теперь обслуживает и CCES данного проекта, что получилось очень логично. Конфиг существует глобально для модуля и CCES тоже.

10) Старые проекты продолжают использовать старые схемы конфигов до тех пор пока не будет возможности исправить их без потери совместимости форматов.

11) Файл конфига не обязателен для приложения

www.biosoft-m.ru



Просмотры
Личные инструменты