Как правильно хранить статичный набор начальных данных в классах?

[mazzy]

Цитата:

Сообщение от konopello

не совсем понял что значит гемороится с ключами, ядро само контролирует ключ.

?!

а! у вас структура хранится два раза: и в ключе, и в значении (value)

Цитата:

Сообщение от konopello

key TYPE myStruct,
value TYPE myStruct,

хорошо, что есть аналог set.

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

[sukhanchik]

Цитата:

Сообщение от mazzy

давайте все-таки вернемся к теме.

А можно уточнить? Что все-таки нужно? Хранить некие константные значения в коде (аналогично моему посту выше) и впоследствии на основе их заполнять некие данные или вести работу с набором переменных данных (например, разноска в ГК и классы LedgerVoucherList, LedgerVoucherTransList).
А то создание всяких коллекций, классов-оберток и т.д. актуально больше не для столько для начальных константных данных, сколько для переменных данных (разноска ГК)

[mazzy]

Цитата:

Сообщение от sukhanchik

А можно уточнить? Что все-таки нужно? Хранить некие константные значения в коде (аналогично моему посту выше) и впоследствии на основе их заполнять некие данные или вести работу с набором переменных данных (например, разноска в ГК и классы LedgerVoucherList, LedgerVoucherTransList).

изначальная тема "хранить статичный набор начальных данных в классах"

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

причем, заполнение набора может проводится как в одном методе, так и в нескольких. например, часть добавляется (или убирается) в методах-потомках.

[sukhanchik]

Цитата:

Сообщение от mazzy

я не очень понимаю в чем выбор между твоими вариантами.

Поясню.
1. Задача создания закладки "Номерные серии" в параметрах модуля. Пользователь ничего не вводит, однако ему выводится некая таблица (грид) значений, которые на самом деле хранятся в коде (контейнер контейнеров, классы, временная таблица - неважно). Важно, что при изменении соответствующего куска кода - данные в этой таблице должны меняться.

В этом случае мне нравится (в порядке убывания):
- вариант таблицы (лучше постоянной - как с номерными сериями)
- вариант XML (в памяти)
- вариант контейнера контейнеров
не нравится вариант класса классов или Set (Types::Class) - т.к. слишком много кода

2. Задача создания разноски в ГК. Тут нет начальных константных данных, однако по входящим данным генерируется некоторый набор записей. Генерируемый набор может быть представлен как набор экземпляров классов (Set Types::Class). Важно - что нам не нужно хранить в классах параметры, т.е. многие параметры входящие

В этом случае мне нравится (в порядке убывания):
- вариант класса классов (на худой конец Set Types::Class)
- вариант таблицы (лучше временной, как промежуточной, хотя может даже лучше и постоянной - т.к. все равно откат произойдет, если не закроется транзакция)
не нравится вариант XML (сложность реализации) и контейнера контейнеров / Map / Set / List (нечитабельный код)

PS. Упс... ответ уже получен - пункт 1. Но все равно - мнение свое выскажу

[mazzy]

Цитата:

Сообщение от sukhanchik

аналогично моему посту выше)

ага, спасибо.

вот суть:
вариант "хранения в коде" сводится к варианту fed - создать таблицу и инициализировать ее в коде.


вариант хранения в ресурсах не рассматривался. спасибо.


итак - аксапта. есть следующие способы хранения статичного набора начальных данных.

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

[sukhanchik]

Цитата:

Сообщение от mazzy

пример инициализации

Не... это плохой пример инициализации. Создается ощущение, что нужно писать много кода в куче в одном месте.

Вот хороший пример:



Каждый наследник заполняет только "свою" часть настроек.

Пример из жизни. Мы оказываем складские услуги сторонним организациям. Мы используем АХ. Каждый клиент присылает документ об отгрузке / приемке в электронном виде и каждый в своем формате. Задача хранить параметры импорта в разрезе форматов данных (на самом деле еще и в разрезе клиента). При этом параметры у каждого формата могут быть разные (типы разные) и количество их также может быть разным.

Создаем механизм, аналогичный номерным сериям. Создаем наследника на каждый тип формата данных. Т.о. в коде у нас создаются записи, каждая из которой отвечает за свой параметр. Какие-то параметры (к примеру, каталог импорта / экспорта) у нас будут общие для нескольких форматов данных => соответствующие строки из метода loadModule можно перенести в родительский класс.

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