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

[konopello]

Цитата:

============================
В С++ я бы написал что-то вроде
struct { int64 refTable; int refField } myStruct;
set<myStruct> myStructSet = ( {Table1, Field1}, {Table2, Field2} );
и получил бы одновременно и контроль типов, и легкость инициализации.

========================

извините что может не в тему но просто для расширения общего познания написал как бы выглядел этот код на ABAP.
============================
TYPE: BEGIN OF myStruct,
table TYPE integer64,
field TYPE integer,
END OF myStruct.

TYPE: BEGIN OF myStructComlex,
key TYPE myStruct,
value TYPE myStruct,
END OF myStructComlex.

TYPE myStructComlexTab TYPE HASH TABLE myStructComlex WITH UNIQUAE KEY key.
============================

[mazzy]

Цитата:

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

извините что может не в тему

не в тему.
и вы не написали как будет выглядеть добавление нескольких значений в эту хэш-таблицу.

если уж речь идет о таблицах, то fed предложил более изящный способ - создать структуру в АОТ. и дальше делать несколько insert'ов. и кода меньше, и проверок больше.

а в аксапте прямой аналог вашего кода - map (вариант я не выписывал с способы из-за явно избыточного key)

myMap = new(Types::string, Types::class);
myMy.add("someKey1", new myPair(table1, field1);
myMy.add("someKey2", new myPair(table2, field2);

чтобы не геммороится с key в аксапте есть класс set. и варианты 2.1, 2.2, 2.3 подразумевали работу именно с этим классом set.

но все равно кода получается слишком много по сравнению с
set<myStruct> myStructSet = ( {Table1, Field1}, {Table2, Field2} );

[konopello]

Цитата:

не в тему.
и вы не написали как будет выглядеть добавление нескольких значений в эту хэш-таблицу.

А будет выглядеть так
================
DATA:
lt_myStructComlexTab TYPE myStructComlexTab,
ls_myStructComlexTab LIKE LINE OF lt_myStructComlexTab.

CLEAR ls_myStructComlexTab.
ls_myStructComlexTab-key-table = 'TABLE1'.
ls_myStructComlexTab-key-field = 'FIELD1'.
ls_myStructComlexTab-value-table = 'TABLE2'.
ls_myStructComlexTab-value-field = 'FIELD2'.
INSERT ls_myStructComlexTab INTO TABLE lt_myStructComlexTab.
================

не совсем понял что значит гемороится с ключами, ядро само контролирует ключ.
если вам это не надо то можно тип таблицы изменить на простую.
================
TYPE myStructComlexTab TYPE STANDARD TABLE myStructComlex.
================
это аналог SET.

извините за за СПАМ.

[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 или какие- еще технологии и я не собираюсь обсуждать в этой ветке плюсы и минусы решения поставленной задачи именно такой реализацией. Однако, я хотел привести пример использования на практике идеи закладки "Номерные серии" как пример заполнения таблицы данными из кода.

[konopello]

Цитата:

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

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

[Владимир Максимов]

Как мне кажется, вопрос о способе записи статических данных "вообще" в отрыве от способа использования этих самых статических данных - не имеет смысла.

Ну, например, разработчики Axapta может и хотели бы хранить данные о номерных сериях в виде контейнеров, но ведь использоваться-то они будут как записи таблицы. Так зачем же вводить промежуточные структуры, если в конце концов все-равно придется создавать записи? Ну, так сразу и создаем.

Т.е. способ дальнейшего использования этих самых статических данных собственно и определяет способ их задания. Все остальные соображения тут же отходят на второй план.

Кроме того, меня несколько удивляет акцентирование внимание на контроле типов данных. Это ты сам себе не доверяешь? Ну, в худшем случае, получишь ты ошибку не на этапе компиляции, а на этапе исполнения. Или написанный код предварительно не тестируется? А почему, собственно, надо контролировать только тип и не надо контролировать значение? Ведь тоже возможна ошибка!

Т.е. контроль типов не то чтобы лишнее требование, но, скорее, из разряда приятных, но не обязательных бонусов. Есть - хорошо, нет - не очень-то и нужно...

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Как мне кажется, вопрос о способе записи статических данных "вообще" в отрыве от способа использования этих самых статических данных - не имеет смысла.

предложи варианты

я говорил о наборе пар <таблица, поле> для редактирования query.
я предполагал что-то сугубо внутренне-программистское. такое что не дается пользователю.

Цитата:

Сообщение от Владимир Максимов

Это ты сам себе не доверяешь?

и сам себе не доверяю - особенно если буду добавлять/изменять что-нибудь через несколько месяцев.
и не доверяю другим программистам - которые будут добавлять/изменять что-нибудь после меня через некоторое время.

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

Цитата:

Сообщение от Владимир Максимов

Ну, в худшем случае, получишь ты ошибку не на этапе компиляции, а на этапе исполнения.

Хе... Это ж большая разница.

Цитата:

Сообщение от Владимир Максимов

Или написанный код предварительно не тестируется? А почему, собственно, надо контролировать только тип и не надо контролировать значение? Ведь тоже возможна ошибка!

А мне нравится эта вывернутая логика:
Конечно же надо контролировать значение - "скажи как".

И мне нравится этот переход на личности:
"раз у тебя код не тестируется, поэтому зачем тебе контроль начальных данных?"

==============
В контейнерах нет контроля ни типа, ни значения.
Я спрашивал - есть ли механизм который контролирует хотя бы тип?
Мне ответили - только создавать свои классы (но достаточно трудоемко)
Мало того, контейнер уж очень неповоротливая структура (хоть и легкая в использовании)

Но в стандартном коде повсеместно используются контейнеры.
А какого-то промежуточного/смешанного способа нет - либо контейнеры, либо классы

Цитата:

Сообщение от Владимир Максимов

Т.е. контроль типов не то чтобы лишнее требование, но, скорее, из разряда приятных, но не обязательных бонусов. Есть - хорошо, нет - не очень-то и нужно...

[mayk]

Цитата:

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

Хе... Это ж большая разница.

Не смертельная. Учитывая удобство, можно и потерпеть. Особенно если не смешивать record'ы и int'ы в одном контейнере.

по теме: зависит от.
контейнеры,

container fields;;
fields = [[#CustAccount, custTable.custAccount],
[#CustId, custTable.accountNum],
etc];
for(i=1;i<=conlen(fields);++i){
 [bookmark, value]=conpeek(fields,i);
 excelDocument.insert(bookmark, value, #worksheet);

иногда hook'и (типа Runbase.dialogPostInit)

void initQuery(){;
   query = new Query(querystr(aotquery));
   postInitQuery(); //наследники могут делать грязную работу здесь, не перекрывая initQuery()

Особенно если предполагается что вызов super'а накладен:

void initQueries(){;
   for(i=1;i<N;++i)
   query = new Query(querystr(aotquery));
   this.postInitQuery(query); 
   this.addQuery(query);//здесь хук для инициализации легче сделать чем super() в DerivedClass.initQueries()

лучше всего вместе с parm'ами

myClass = myClass::construct(/**/);
myClass.parmQuery().dataSourceTable(xx).range(...);

List'ы и struct'ы на этапе компиляции всё равно не поймают ошибку типов. И вроде не на ембеддеде клиент запускается, чтобы сильно о памяти беспокоиться.

[Владимир Максимов]

Цитата:

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

я говорил о наборе пар <таблица, поле> для редактирования query.
я предполагал что-то сугубо внутренне-программистское. такое что не дается пользователю.

Как "стандартно" задается пара <таблица, поле> для будущего Range? Очевидно, через функции tablenum(), fieldnum(). И вот КАК здесь можно ошибиться? Приведи пример.

Это очень показательный пример того, что без знания цели, выбор "идеального" средства - бессмысленное занятие

Цитата:

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

А мне нравится эта вывернутая логика:
Конечно же надо контролировать значение - "скажи как".

Ну, это просто. Если известно, что речь идет о паре: таблица-поле, то, очевидно, можно проконтролировать корректность Id-таблица и корректность Id-поля. Только вот, не кажется ли, ну, мягко говоря, странным подобное занятие? Разве tablenum() и filednum() в принципе могут дать не корректное значение?

Цитата:

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

И мне нравится этот переход на личности:
"раз у тебя код не тестируется, поэтому зачем тебе контроль начальных данных?"

Это не "переход на личности". Это доведение до абсурда, чтобы показать не корректность исходной постановки задачи.

Ведь насколько я понимаю, Вы не ставите задачу проверки значения не потому, что это невозможно "в принципе". Как раз-таки очень даже возможно. Просто Вы понимаете полную бессмысленность этой задачи. Однако контроль типов Вам не кажется бессмысленным. Почему, собственно? Только потому, что это относительно просто?

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Как "стандартно" задается пара <таблица, поле> для будущего Range? Очевидно, через функции tablenum(), fieldnum(). И вот КАК здесь можно ошибиться? Приведи пример.

легко. здесь выкладывают проекты.
проекты могут быть импортированы в среду, где таких таблиц нет.

другой вариант: дев и продакт системы.
в дев таблицы и поля есть, а в продакт еще не перенесли.

или вот так: Несколько AOS: синхронность изменения объектов

Цитата:

Сообщение от Владимир Максимов

Это очень показательный пример того, что без знания цели, выбор "идеального" средства - бессмысленное занятие

Как скажете

Цитата:

Сообщение от Владимир Максимов

Ведь насколько я понимаю, Вы не ставите задачу проверки значения не потому, что это невозможно "в принципе". Как раз-таки очень даже возможно. Просто Вы понимаете полную бессмысленность этой задачи. Однако контроль типов Вам не кажется бессмысленным. Почему, собственно? Только потому, что это относительно просто?

[Evgeniy2020]

Я бы может генерил бы на основе таблиц и полей, или классов (метаданных)
XML формы для ввода, что то вроде ASP.net или веб сервис,
и не программист мог бы вводить данные с привязкой к метаданным (не по id а возможно символьно)

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

можно было бы сделать веб сервис поставщик данных, на основе того что вводят не программисты. в веб поля которые генерятся на основе дев метаданных.

[Владимир Максимов]

Цитата:

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

легко. здесь выкладывают проекты.
проекты могут быть импортированы в среду, где таких таблиц нет.

другой вариант: дев и продакт системы.
в дев таблицы и поля есть, а в продакт еще не перенесли.

или вот так: Несколько AOS: синхронность изменения объектов

Во всех описанных случаях при использовании tablenum() и fieldnum() будет ошибка на этапе компиляции. Импорт не получится. Нет причин в дополнительном контроле не только значений, но и типов данных.

Можно привести еще варианты, когда при вводе констант (статических данных) действительно необходим дополнительный контроль типов этих самых констант?

[Владимир Максимов]

Цитата:

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

предложи варианты

я говорил о наборе пар <таблица, поле> для редактирования query.
я предполагал что-то сугубо внутренне-программистское. такое что не дается пользователю.

Предлагаю

Для начала, небольшое отступление. Когда я начал программировать в среде X++ я считал "не правильным" создавать временные таблицы в AOT. Логика здесь была такая: данные временные, значит, и все объекты, которые их используют должны быть временными. В том смысле, что они должны быть удалены по окончании работы кода. А объект AOT остается! Т.е. "временный объект" оказывается "постоянным".

В настоящее время, я рассматриваю временные таблицы, как программный код написанный визуальными средствами. Это позволяет избавится от психологического "затыка".

Так вот, возвращаясь к задаче. Если сама задача заключается в создании/изменении query, то, почему-то вариант создания этого самого query напрямую в AOT не рассматривается в принципе. "По определению". Почему собственно? Думаю, по двум причинам:

1. Тот психологический "затык", который я описал чуть выше
2. В отличие от временной таблицы query можно создать программно

Итого, предлагаю вариант прямого создания Query в AOT. Со всеми предопределенными Range.

=============================================

Ну, хорошо, предположим, "ломка" настолько сильная и не преодолимая, что заставить себя создать объект в AOT - невозможно . Ладно. Тогда переходим к "программистским" трюкам

Как правило, для построения query создается отдельный метод класса вроде BuildQuery. И вот тут еще один интересный вопрос.

А зачем вообще надо предварительно "запихивать" поля в какое-то промежуточное хранилище, если можно прямо так и писать код создания с явным указанием имен полей? Ну, там

queryBuildDataSource.addRange(fieldnum(...))

Зачем здесь "лишние" посредники? Хотите модифицировать query в классах-наследниках? Да пожалуйста! Есть куча методов для этого - clearRange(), findRange() и т.п.

==============================

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

Это как-раз стандартный подход в Axapta.

===============================

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

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

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Так вот, возвращаясь к задаче. Если сама задача заключается в создании/изменении query, то...
...у нас стоит задача иметь возможность делать query с разными таблицами-источниками...

Владимир Максимов, вы тормоз.
Тема называется: Как правильно хранить статичный набор начальных данных в классах?

[S.Kuskov]

Цитата:

Сообщение от Владимир Максимов

А зачем вообще надо предварительно "запихивать" поля в какое-то промежуточное хранилище, если можно прямо так и писать код создания с явным указанием имен полей? Ну, там

queryBuildDataSource.addRange(fieldnum(...))

Зачем здесь "лишние" посредники? Хотите модифицировать query в классах-наследниках? Да пожалуйста! Есть куча методов для этого - clearRange(), findRange() и т.п.

Цитата:

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

Ок, например, Query не позволяет удалять Range. Поэтому, по-уму надо бы сначала провести оптимизацию range'й.

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

.