F
fedotxxl
Привет, кто что думает по такому вопросу:
Для хранения настроечных данных мы используем лотусовые документы. Далее пишутся классы обертки на эти документы и методы нахождения этих документов по разным критериям через виды. Соотв. схема такая:
1. Нашли документ по критерию
2. Считали инфу
3. Что-то сделали
Документы редактируются редко, но хранят достаточно большой объем инфы.
Что если: программно один раз создать на каждый документ свой экземпляр класса? Соотв мы документы меняем на классы. При инициализации программа создает по одному экземпляру каждого класса и для поиска и чтения информации нам уже не требуются виды, документы и т.д.
Зачем это, возможно, нужно:
1. Настроечные документы фактически являются некими элементами дизайна. Если мы создадим их в видем библиотек, то они будут реально являться экземплярами дизайна. Нужно для контроля версионности, напрмер
2. LN на каждый объект создает C++ реализацию => меньше объектов LN, меньше C++ реализаций
3. В теории поиск по list'у в разы быстрее, чем по виду
Недостатки:
1. Непонятно, как будет работать на больших объемах
2. Непонятно, как долго будет все инициализироваться
3. Непонятно сколько памяти будет расходоваться
4. В момент старта необходимо прогрузить все настроечные докуметны в память, хотя потребоваться нам могут лишь часть (думаю, эту проблему можно как-то решить)
Для хранения настроечных данных мы используем лотусовые документы. Далее пишутся классы обертки на эти документы и методы нахождения этих документов по разным критериям через виды. Соотв. схема такая:
1. Нашли документ по критерию
2. Считали инфу
3. Что-то сделали
Документы редактируются редко, но хранят достаточно большой объем инфы.
Что если: программно один раз создать на каждый документ свой экземпляр класса? Соотв мы документы меняем на классы. При инициализации программа создает по одному экземпляру каждого класса и для поиска и чтения информации нам уже не требуются виды, документы и т.д.
Зачем это, возможно, нужно:
1. Настроечные документы фактически являются некими элементами дизайна. Если мы создадим их в видем библиотек, то они будут реально являться экземплярами дизайна. Нужно для контроля версионности, напрмер
2. LN на каждый объект создает C++ реализацию => меньше объектов LN, меньше C++ реализаций
3. В теории поиск по list'у в разы быстрее, чем по виду
Недостатки:
1. Непонятно, как будет работать на больших объемах
2. Непонятно, как долго будет все инициализироваться
3. Непонятно сколько памяти будет расходоваться
4. В момент старта необходимо прогрузить все настроечные докуметны в память, хотя потребоваться нам могут лишь часть (думаю, эту проблему можно как-то решить)