Как правильно хранить статичный набор начальных данных в классах? - Страница 3 - DAX: Программирование

**mazzy** · 12.04.2011, 21:34

Цитата:

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

Это я к тому что в мета данных вне Ах хранить числовые значений не стоит.[/I]

Я так понимаю, что у участников идеи по самой теме кончились, раз пошли боковые ветки.

Ок. Тогда попробую подвести итоги:
1. контейнер значений (в т.ч. контейнер контейнеров)
плюсы:
= очень просто инициализировать значения, легко добавлять/изменять значений
= стандартный функционал работает с контейнерами, поэтому проблем с примером использования не будет
= единственный способ сериализации, приемлемый для передачи параметров между клиентом и сервером (за таблиц, конечно)

минусы:
= контейнер - константа. ВСЕГДА. любая попытка изменить контейнер приводит к пересозданию контейнера. что чревато проблемами производительности для больших наборов
= контейнер - содержит только константы. не содержит ссылки. поэтому хранить ссылку на класс внутри контейнера нельзя
= никакой встроенной проверки типов. нужно писать самому
= никакой встроенной проверки количества данных. нужно писать самому. или надеятся на добросовестность программиста

пример инициализации:
container parm = [['<html>','</html>'],['<body>','</body>']];
container parm = [[myTable1, myField1], [myTable2, myField2]];

пример использования:
= pack/unpack
= класс keySum

2. класс (set, list, map и т.п.)
плюсы:
= контроль типов присутствует (хоть и минимальный)
= класс не пересоздается в памяти при изменении

минусы:
= писать нужно гораздо больше кода чем с контейнерами

примеры использования:
???

2.1. класс (set, list, map и т.п.), хранящий экземпляры специально написанного класса
плюсы:
= полный контроль над значениями

минусы:
= писать надо очень много

пример инициализации:
set mySet = new Set(Types:Class);
mySet.add(new MyParm(myTable1, field1));
mySet.add(new MyParm(myTable2, field2));

пример использования:
???

2.2. класс (set, list, map и т.п.), хранящий struct:
плюсы:
= не надо писать собственного класса

минусы:
= struct не делает контроля обязательности
= очень многословная запись

пример инициализации:
set mySet = new Set(Types:Class);
struct myStruct = new Struct(Types::Integer, "age", Types::String, "name");
myStruct.value("name","Jane Dow");
myStruct.value("age", 34);
mySet.add(myStruct);

myStruct.value("name","Tom Gun");
myStruct.value("age", 45);
mySet.add(myStruct);

пример использования:
???

2.3. класс (set, list, map и т.п.), хранящий контейнеры:
= даже не знаю

минусы:
= бу-э-э-э... способ объединяет минусы всех способов

пример инициализации:
set mySet = new Set(Types:Class)
mySet.add([myTable1, field1]);
mySet.add([myTable2, field2]);

пример использования:
FactureCalcBalances_RU

3. таблицы
плюсы:
= полный контроль
= эффективная передача клиент/сервер
= достаточно очевидно для любого програмиста

минусы:
= нужно писать кода не меньше, чем в случае 2.1 "класс собственных классов"

пример использования:
NumberSeqReference.loadModule()
NumberSeqReference_Ledger.loadModule()

4. xml-файл в ресурсе
плюсы:
= удобно передавать вместе с приложением. особенно большие наборы данных

минусы:
= очень неочевидно для программистов
= работа с xml ресурсоемка

пример использования:
\Data Dictionary\Tables\BITimePeriodsMDX\Methods\importFromAOT

так? вроде ничего не забыл?

**sukhanchik** · 12.04.2011, 22:38

По п. 2.1 пример - разноска в ГК: класс LedgerVoucherList - обертка Map, состоящий из объектов LedgerVoucherObject. Здесь формируется список проводок в ГК по ваучеру. (см. класс LedgerVoucher и метод addVoucher)
Другой пример: Объекты List и Map, хранящие в себе список контролек диалога. List хранит упорядоченный список (см Dialog.addCtrlDialogField()), а Map - ссылки на объекты (Dialog.addFieldCon() и Dialog.addDialogClass())

Struct (согласно перекрестным ссылкам) используется для задания свойств объекта. В частности у контрольки в DialogField и в классе WebApplication (тут есть типизация, а не только String)

CDR · 12.04.2011, 23:27

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

) на:

заполнение этой коллекции данными
на извлечение данных из этой коллекции для их последующей обработки

Поясню на примере.
Что подразумевает использование отдельно-выделенного хранилища данных? Использование как-минимум двух методов.
1. Метод, в котором коллекция заполняется данными.

X++:

void initDataCollection()
{
    ;
    dataCollection = new DataCollection(Type);
    dataCollection.append(data1);
    dataCollection.append(data2);
    dataCollection.append(data3);
    dataCollection.append(data4);
    .....
}

2. Метод, в котором данные извлекаются из коллекции в каком-то цикле для последующей обработки.

X++:

void processDataCollection()
{
    while(dataCollection.more())
    {
        processData(dataCollection.getData());
        dataCollection.next();
    }
}

Т.е. сначала СТАТИЧЕСКИЕ данные запихиваются в ДИНАМИЧЕСКУЮ коллекцию, что бы потом их оттуда обратно извлечь. Какой смысл в этих действиях? Что мешает использовать один метод, в котором сразу и вызывать обработку СТАТИЧЕСКИХ начальных данных (данных по умолчанию)?
3. Метод, в котором сразу обрабатываются статические данные без заморочек со всякими коллекциями-хранилищами.

X++:

void processDefaultData()
{
    ;
    processData(data1);
    processData(data2);
    processData(data3);
    processData(data4);
    ....
}

ИМХО, в подавляющем большинстве Аксаптовых случаев это наиболее простой, быстрый, наглядный, гибкий и т.д. способ обработки статичных начальных данных без всяких коллекций и хранилищ.

**mazzy** · 12.04.2011, 23:48

Цитата:

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

X++:

void processDefaultData()
{
    ;
    processData(data1);
    processData(data2);
    processData(data3);
    processData(data4);
    ....
}

ИМХО, в подавляющем большинстве Аксаптовых случаев это наиболее простой, быстрый, наглядный, гибкий и т.д. способ обработки статичных начальных данных без всяких коллекций и хранилищ.

да, спасибо.
во-первых, я забыл записать этот способ. а он обсуждался.
это будет способ 5.

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

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

X++:

class foo
{
    void processDefaultData()
    {
        ;
        processData(data1);
        processData(data2);
        processData(data3);
        processData(data4);
        ....
    }
....
}

class fooBar extends foo
{
    void processDefaultData()
    {
        ;  // как в этом методе изменить/убрать из списка data3?
        super();
        processData(data5);
        ....
    }
}

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

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

CDR · 13.04.2011, 00:25

Цитата:

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

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

Если processData будет еще не реентерабельным, то задача обработки однотипных данных для коллекции не решается в принципе. В то же время в 5-ом способе запросто можно написать метод processDataSpecial() и вызвать его для нужных data2 и data4, например.

Цитата:

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

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

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

Цитата:

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

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

Задача на грани невероятного для статического набора данных.

Владимир Максимов · 13.04.2011, 12:37

Цитата:

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

вы так уперлись в функции tablenum и fieldnum.

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

Либо константы не являются константами в прямом смысле этого слова (tablenum() - это НЕ константа), либо никто и никогда не контролирует тип этих констант. В смысле, не пишет функционала по этому контролю

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

Цитата:

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

код цвета, тег html, шрифт, размеры шрифта, GUID, MAC-адрес, ip-адрес, адрес сайта в интернете, параметры границы, размеры окон по умолчанию, avi-файл отображения в progressBar, фигуры для тетриса, список начальных вопросов-ответов для Элизы, а также любые другие константы, например из аксаптовских макросов.

тысячи их.

Замечательно. А теперь приведите пример кода, где бы был прописан функционал контроля типа этих самых констант.

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

PS: Ну, считайте, я "прицепился" к фразе

Цитата:

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

минусы:
= никакой встроенной проверки типов. нужно писать самому
= никакой встроенной проверки количества данных. нужно писать самому

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

S.Kuskov · 13.04.2011, 13:20

Цитата:

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

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

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

Владимир Максимов · 13.04.2011, 14:39

Цитата:

Сообщение от S.Kuskov

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

Какое отношение это все имеет к контролю типов и значений "параметров"?

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

Вот когда Вы создаете новую номерную серию, каким образом Вы определяете что надо заполнить в loadModulе()? Неужели из интерфейса все понятно?

S.Kuskov · 13.04.2011, 14:55

Цитата:

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

Какое отношение это все имеет к контролю типов и значений "параметров"?

post #33

Цитата:

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

например, создан вместо контейнера Struct, или MAP, или временная таблицы. И как Вы собираетесь угадывать "что есть что" в этом "чудо-хранилище"? Опираясь на имена?

Ну скажем так, игнорировать имена я уж точно не буду. Если я знаю что мне нужно указать пару "id столбца" - "значение", то Id поля я запишу в поле с именем FieldId а значение в поле с именем Value, а не наоборот. В случае с контейнером это совсем не очевидно.

Владимир Максимов · 13.04.2011, 17:39

Цитата:

Сообщение от S.Kuskov

Ну скажем так, игнорировать имена я уж точно не буду. Если я знаю что мне нужно указать пару "id столбца" - "значение", то Id поля я запишу в поле с именем FieldId а значение в поле с именем Value, а не наоборот. В случае с контейнером это совсем не очевидно.

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

Получается, что если элементов структуры мало, то ориентироваться в них достаточно просто вне зависимости от того, есть имя или нет. А если элементов структуры много, то ориентироваться в них сложно, опять же, вне зависимости от того, есть имя или нет.

S.Kuskov · 13.04.2011, 18:43

Цитата:

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

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

Хорошо. В отдельно взятой простой структуре ориентироваться просто и без имён. Но мы говорим о системе, количество классов в которой измеряется тысячими. Если разработчик будет вынужден держать в голове мелочи подобные этим, ему сложно будет мыслить глобально. Разработчик в аксапте должен мыслить понятиями бизнесс-процессов, а не порядковыми номерами элементов. Это производители низкоуровневых драйверов могут позволить себе играться с побитывыми операциями

, а в аксапте чем нагляднее тем лучше.

Цитата:

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

А если элементов структуры много, то ориентироваться в них сложно, опять же, вне зависимости от того, есть имя или нет.

Но при наличии имён на порядок проще. Проще и в плане написания той же самой документации.

P.S.: по-мойму оффтоп получается

Владимир Максимов · 14.04.2011, 11:13

Цитата:

Сообщение от 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** · 14.04.2011, 11:17

Цитата:

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

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

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

Владимир Максимов · 14.04.2011, 11:22

Чем объект AOT отличается от статического набора?

S.Kuskov · 14.04.2011, 11:26

Цитата:

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

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

queryBuildDataSource.addRange(fieldnum(...))

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

Цитата:

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

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

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

.

**mazzy** · 14.04.2011, 11:28

Цитата:

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

Чем объект AOT отличается от статического набора?

можно и в AOT.
об этом был способ №4 "xml-файл в ресурсе"
и способ №5 "Метод, в котором сразу обрабатываются статические данные без заморочек со всякими коллекциями-хранилищами"

"query в AOT" - частный случай для инициализации с query.
мало того, именно такой способ я и рекомендовал всегда для работы с кверями.
ищите по ключевому слову "querystr"

просто тема не о кверях.

Владимир Максимов · 14.04.2011, 11:50

Цитата:

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

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

Цитата:

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

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

Именно это я и делаю. Предлагаю варианты конкретных ситуаций, поскольку по прежнему считаю, что просто нет единого "правильного" способа хранения статических данных. Тот или иной вариант является прямым следствием конкретной задачи. Говорить "вообще" - это говорить "ни о чем"

Исходная постановка задачи после всех уточнений, замечаний, разных "но" и "если" выглядит довольно странно. Примерно так:

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

И что здесь можно ответить? Да любой объект, который может хранить списки подходит для этого! Хоть обычные массивы. Другой вопрос, а подходит ли выбранное решение для конкретной ситуации?

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

**mazzy** · 14.04.2011, 11:59

Цитата:

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

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

Ок. Понял.
На ваш взгляд:
1. В Аксапте нет универсального способа хранения статических данных
2. для Query лучше хранить сам query в AOT.

Владимир Максимов, я отключюсь в этой ветке от общения с вами. Извините.

Другие мнения/дополнения будут?

mayk · 14.04.2011, 12:10

Вот, кстати, вспомнилось. Не совсем начальные данные, правда, но всё равно показательно.

Пример использования контейнеров в системе когда не надо использовать контейнеры, а надо таблицы: RTax25RegisterTrans.RegsiterValues. там хранится около дюжины самых разнотипных полей.
См. например LedgerJournalCreate_Tax25AmountDiff_RU

Код:

        ledgerJournalTrans.DocumentNum           = conpeek(registerTrans.RegisterValues, #Value3);
        ledgerJournalTrans.DocumentDate          = conpeek(registerTrans.RegisterValues, #Value4);

Ещё вот как хорошо сделано в RAssetAdvancedAssessedTaxDeclaration

Код:

        taxPay += (this.round(conpeek(_trans.RegisterValues, #Value10)) -
                   this.round(conpeek(_trans.RegisterValues, #Value13)));

Очень легко читать и отлаживать /s.

Надеюсь, когда нибудь проверка BP научится бить по рукам за #define.Value13(13) от которого толку - ноль.

Ещё один плюс таблиц перед containerами: фильтры. Помню была доработка по этим RTax25* где надо было выбирать определенные RegisterValues. Так как делать joinы и фильтры на container'ы внутри таблиц нельзя, то приходилось перебирать все RTax25RegisterTrans принадлежащие RTax25RegisterTable'у.

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Загрузка начальных данных	MIVura	DAX: Прочие вопросы	1	31.03.2009 14:52
Набор данных на лету	HorrR	DAX: Программирование	15	26.09.2008 15:21
Прогноз роста базы данных и выбор топологии системы, Как правильно расчитать возможный рост	sergeypp	DAX: Администрирование	0	05.12.2006 16:55
Введение в Аксапту	Роман Кошелев	DAX: Прочие вопросы	0	18.12.2001 14:00

Опции темы	Поиск в этой теме
Версия для печати Отправить по электронной почте	Поиск в этой теме: Расширенный поиск
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид