В чем преимущество ax-классов перед непосредственной работой с таблицами?

[mazzy]

Цитата:

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

Mazzy - ну написали люди классы ВНУТРИ AX, теперь пользуются ими внутри AX, что здесь такого? Оба способа приемлимы, так что это дело вкуса и привычки.

mifi, я верю. и не спорю, что приемлемы.

я хочу ПОНЯТЬ - что побудило их написать?
и что лучше использовтать в текущей версии аксапты?

практический смысл вопроса очень простой:
= надо ли заморачиваться и делать ax-обертки для своих таблиц/полей?
= нало ли заморачиваться и требовать от локализации наличия таких ax-оберток?

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

[fed]

Цитата:

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

Нет, метод будет исполнен на сервере.

Не поленился, нашел нужную справку. Похоже что мы оба неправы:
http://msdn.microsoft.com/en-us/library/aa634829.aspx
Про "Table kernel method (update, insert, and so on)," пишут что они "Called from (unless overridden)". То есть - если никаких дополнительных извратов не делать, то метод insert() вызванный с формы будет исполняться на клиенте (поскольку слой исполнения наследуется от формы). НО: В комментариях написано "You can override the table Called fromRunOn property value by using server or client modifiers in the method declaration."
То есть - получается что в 2009ой втихаря разрешили ставить server/client не только перед статическими методами, но и перед встроенными instance-методами.
Кстати, любопытно что в 4ой версии, текст подсказки тот же самый: (http://msdn.microsoft.com/en-us/libr...(v=AX.10).aspx)

То есть, оказывается встроенные методы можно перекидывать на сервер, но автоматически это не делается. Интересно - начиная с какой версии?

[Wamr]

После того как познакомился с сериализацией (перевод объектов в XML) в .Net решил, что ax-классы - это промежуточный слой позволяющий без лишнего кодирования(?) получать из записей таблиц XML-документы и обратно из XML данные.
Естественно, при получении данных должна проходить какая-то обработка, которая и была реализована. В результате получились 2 механизма работы с данными. В DAX делались шаги по их объединению, но как-то это не стало "новой политикой" разработки повсеместно, да и поддерживать механизмы интеграции, если не планируешь их использовать получается накладно.

[gl00mie]

Цитата:

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

IMHO - за исключением узкой задачи сериализации документов, эти классы не функциональны.

Ага... читаем "What's New - Technical in Microsoft Dynamics AX 2012 for Development" про мечту 95% пользователей Аксапты (выделение курсивом - мое):

Цитата:

Редактирование данных в Excel
За счет использования Microsoft Dynamics AX 2012 Office Add-ins редактировать можно будет любые данные, опубликованные в виде доступного сервиса. Для этого подключитесь к AOS, укажите нужный сервис, перетащите поля, которые вас интересуют, в книгу Excel, обновите данные, чтобы заполнить книгу, затем отредактируйте их и нажмите кнопку, чтобы отразить изменения в системе. Редактирование данных в Excel включает следующие возможности:

• Интеграция с сервисами документов. Информация из любого сервиса может быть прочитана, изменена и обновлена в AX 2012 с полной поддержкой контроля доступа и сопутствующей бизнес-логики.
• Office Add-ins используют lookup'ы и инфраструктуру запросов из AX 2012.
• Можно определить матричные поля для агрегирования данных. При сохранении измененных значений матричных полей поля всех записей, на основе которых были получены агрегированные значения, будут пропорционально изменены.
• etc.

Цитата:

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

В чем преимущество ax-классов перед непосредственной работой с таблицами ВНУТРИ самой аксапты?

Тут можно вспомнить Программирование и конфликты 2.0 Роберта Гласса:

Цитата:

С точки зрения учебного процесса наука состоит из фундаментальных принципов, которые можно выделить и изучать и которые являются истинными. Каковы основополагающие начала программной инженерии? Некоторые говорят, что программная инженерия – это «гуманитарная наука», что не так-то просто установить ее основополагающие начала.
Я хотел бы предложить свой вариант. Моим кандидатом на роль основополагающего начала программной инженерии выступает понятие, которое мой коллега Ли Макларен (Lee MacLaren) из компании Boeing Military Aircraft называет «однототочечным управлением» (single-point control).
При такой организации вычислений задача, которая должна решаться в нескольких местах, решается только в одном, а во всех остальных местах на это одно лишь ссылаются при необходимости. В качестве самого распространенного примера такого управления можно привести программный модуль, например, библиотечную подпрограмму. Если нам требуется извлечь квадратный корень или выполнить сортировку в нескольких местах в программе, то мы не пишем всякий раз один и тот же программный код, решающий эту задачу. Этот код мы располагаем в каком-то одном месте и обращаемся к нему (вызываем его) по мере необходимости.
Почему мы это делаем? Конечно, потому, что такой код занимает меньше места. Разумеется, потому что это упрощает программную логику. И потому, что если необходимо изменить программный код, то это достаточно сделать один раз.

В Программисте-прагматике этот принцип называется DRY (don't repeat yourself). Бизнес-логика должна быть реализована в одном месте приложения, а не продублирована в куче мест, и при этом ее должно быть удобно использовать из других различных мест приложения (или даже из сторонних интегрируемых с приложением систем). При работе с теми же табличными данными через интерфейс клиента Аксапты очень просто реализовать бизнес-логику на основе вызываемых этим клиентом стандартных обработчиков modifiedField/validateField, при этом за счет интерфейса можно ограничить пользователя в том, в каком порядке и какие поля он сможет изменять. Когда же требуется проделать то же самое из кода, то с точки зрения разработчика таблицы порядок заполнения полей контролировать нельзя, равно как и нельзя обеспечить соответствующие вызовы modifiedField (в результате чего могут вызываться initFromXX). Получается, бизнес-логику нужно дублировать и поддерживать два разных "API": один - для работы через интерфейс (который не позволит выбрать договор, пока не задан тот же код клиента, и который приведет к вызову initFromCustTable() при смене кода клиента), а другой - для работы из кода, где нужно помнить, что сперва надо вызвать clear(), затем initValue(), затем - initFromCustTable(), после этого дернуть transferContractAccount_RU() и указать ему, чтобы не задавал лишних вопросов... Если напутать с порядком вызова методов, то установленные вами значения будут перезаписаны, и на выходе получится не то, что вы ожидали, если не дернуть вообще нужный обработчик, то не подтянутся значения связанных полей ("эй! мы всю жизнь просто заполняли одно это поле из кода - и все, откуда взялись связанные с ним поля?"). А так можно просто "набросать" те значения полей, которые известны, причем в любой последовательности, дернуть нужный обработчик - и он "размотает" всю логику заполнения записи и вызовет нужные обработчики в том порядке, в каком надо, а за счет пометки "тронутых" нами полей их значения гарантированно не будут перезаписаны в ходе этого процесса.

Цитата:

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

я хочу ПОНЯТЬ - что побудило их написать?

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

Цитата:

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

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

На первый вопрос, по-моему, нет однозначного ответа: реализация ax-оберток для таблиц довольно трудоемка и потому не всегда оправдана. Что же касается второго вопроса - по-моему, однозначно надо этим заморачиваться Иначе получается, что без доработки напильником достаточно мощных стандартный механизм нельзя использовать для таблиц, затронутых локализацией.

[mifi]

Цитата:

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

mifi, я верю. и не спорю, что приемлемы.

я хочу ПОНЯТЬ - что побудило их написать?
и что лучше использовтать в текущей версии аксапты?

практический смысл вопроса очень простой:
= надо ли заморачиваться и делать ax-обертки для своих таблиц/полей?
= нало ли заморачиваться и требовать от локализации наличия таких ax-оберток?

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

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

[mifi]

Цитата:

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

Не поленился, нашел нужную справку. Похоже что мы оба неправы:
http://msdn.microsoft.com/en-us/library/aa634829.aspx
Про "Table kernel method (update, insert, and so on)," пишут что они "Called from (unless overridden)". То есть - если никаких дополнительных извратов не делать, то метод insert() вызванный с формы будет исполняться на клиенте (поскольку слой исполнения наследуется от формы). НО: В комментариях написано "You can override the table Called fromRunOn property value by using server or client modifiers in the method declaration."
То есть - получается что в 2009ой втихаря разрешили ставить server/client не только перед статическими методами, но и перед встроенными instance-методами.
Кстати, любопытно что в 4ой версии, текст подсказки тот же самый: (http://msdn.microsoft.com/en-us/libr...(v=AX.10).aspx)

То есть, оказывается встроенные методы можно перекидывать на сервер, но автоматически это не делается. Интересно - начиная с какой версии?

Fed, ты мне напоминаешь немца из старинного анекдота:
"Что будут делать англичанин и немец, если их попросят ответить на вопрос, как выглядит жираф?
Англичанин поедет в Африку, увидит жирафа и запишет, что он видит.
А немец? А немец запрется в кабинете и начнет представлять себе, как может выглядеть жираф"
Мы же не читатели, а разработчики . Открой таблицу SalesLine в AX 2009 и попробуй написать client в определение метода insert() и опиши, что ты увидешь.
Переопределять то, где вызывается метод можно для собственных методов,созданных на таблицах, в этом смысле таблица действительно called from.

[mazzy]

Цитата:

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

Сторонние системы...

Угу. Тоже сторонние системы..

Цитата:

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

Что не запрещает их использовать для каких-либо других целей.

как я уже говорил: "и не спорю, что приемлемы."
я хочу ПОНЯТЬ.

Цитата:

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

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

mifi, это обсужение начинает быть похожим на вопросы oukudao.
Я знаю куда обращаться. И знаю что делать, если есть сценарии.

я хочу понять - ЗАЧЕМ?

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

[mifi]

Цитата:

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

Угу. Тоже сторонние системы..


как я уже говорил: "и не спорю, что приемлемы."
я хочу ПОНЯТЬ.


mifi, это обсужение начинает быть похожим на вопросы oukudao.
Я знаю куда обращаться. И знаю что делать, если есть сценарии.

я хочу понять - ЗАЧЕМ?

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

mazzy - есть некий код, реализующий бизнес-логику. Посмотри, например на AxSalesTable.setDimension(). Да, изначально он был cкорее всего написан для задач интеграции.
Почему мне, как разработчику AX нельзя использовать этот код сейчас для своих нужд? Есть полезный код, я могу его использовать и использую. Зачем - чтобы избежать повторного написания того же самого кода.

[mazzy]

Цитата:

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

Почему мне, как разработчику AX нельзя использовать этот код сейчас для своих нужд?

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

Повторяю свой вопрос:

Цитата:

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

Вопрос: а в чем преимущество ax-классов? в чем была задумка авторов, которые придумали эти соглашения по ax-классам?

Какие еще будут мнения, кроме тривиального "сделано для работы из внешних систем"?

[gl00mie]

Цитата:

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

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

Были причины, и чем дальше, тем больше. Когда приложение начинает разрастаться, а потом вдруг нужно добавить какую-нить логику для поля, ранее фактически не использовавшегося, то очень жалеешь, что подобные ax-классам механизмы не использовались ранее, ведь так было бы просто подпилить один класс и, к примеру, автоматом получить заполнение нового поля таблицы в сотне мест, где создаются в ней записи. А из-за того, что прежде годами и ты сам, и люди до тебя, да и разработчики стандартного приложения использовали подход clear/initValue/initFromXX/insert (хорошо еще, если initFromXX, а то бывает и тупое заполнение отдельных полей), получается, что нужно по перекрестным ссылкам все эти места найти, допилить совершенно одинаковым образом (ненавистный copy-paste! ), не ошибиться еще при этом нигде, а потом на каждом новом service pack'е и hotfix rollup'е проделывать эту работу заново. Переделывать же весь такой код на ax-классы - обычно задача просто неподъемная, особенно если существенная часть такого кода - в стандартном приложении.
Или взять тот же подход с классами, завязанными на тип записи: все это прекрасно и чудесно, только непоследовательность губит всю затею на корню. Сколько раз в коде приходилось встречать конструкции вида "если тип такой-то или такой-то, то делаем то-то". Какого ж [censored] было заводить тогда семейство отдельных классов? Надо, допустим, сделать новый тип журнала, во много схожий с уже существующим, а как глянешь по перекрестным ссылам, сколько прямых завязок на этот существующий тип журнала - просто руки опускаются... Вот и с ax-классами также: все в них хорошо (ну... подумаешь, привычная логика заполнения полей вывернута на изнанку), вот только когда "созреваешь" для их использования, то объем модификаций, необходимых, чтобы привести все к "каноническому виду", просто вгоняет в депрессию, и хочется пожелать "всего хорошего" тем твоим предшественникам, которые некогда сэкономили время, поленились нормально написать код, а тебе теперь - отдуваться...

[mazzy]

Цитата:

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

Были причины...
////
...Переделывать же весь такой код на ax-классы - обычно задача просто неподъемная...

Хочешь сказать, что начали рефакторинг, но не смогли закончить и выпустили в таком виде?
Другими словами, "не надо привлекать злой умысел, когда достаточно простого бардака"?

Хм... Надо подумать.

[Zabr]

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

[erudit]

Так называемые AxBC-классы (с префиксом Ax) появились в AX 4.0 вместе с Axd-классами, как основа нового модуля AIF (Application Integration Framework).
AIF c Axd-документами пришёл на смену Commerce Gateway с XCBL схемами из Axapta 3.0, который не оправдал себя ввиду сложности добавления новых документов.
Axd-классы вместе с AxBC позволили легко добавлять и управлять новыми XML-документами для обмена данными между AX и другими системами (к примеру, в Axapta 3.0 Commerce Gateway - было всего 3 стандартных документа, в AX 4.0 AIF - 21, а в AX 2009 - уже 58).
Основная задача AxBC классов - управление defaulting'ом:
"
In order to solve intra-table field relations, where a table field should be defaulted to a specific value, when the value of another table field changes
"
Ранее упомянутая технология touched - используется для определения, было ли данное поле изменено ранее, и если да, то defaulting его не тронет. Это принциальное отличие от использования к примеру метода modified() на таблице, где легко перезаписать уже имеющиеся данные. К примеру, если вы получаете от клиента через AIF sales order (AxdSalesOrder-документ), из XML-файла в класс AxSalesLine передаются данные, скажем ItemId и SalesQty, и все остальные поля будут заполненны благодаря defaulting-функциональности AxSalesLine, но поле SalesQty - измененно не будет и сохранит данные из XML - такое стандартными средствами таблиц не сделаешь.
Также много других мелких положительных ньансов в использовании AxBC-классов в AIF, а не таблиц напрямую. К примеру, можно делать подмену значений прямо на лету (internal -> extrnal value и т.п.), что активно используется в InterCompany (заметьте - AxBC-классы предназначены только для использования в AIF или InterCompany, больше нигде).

[mazzy]

Цитата:

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

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

Можно подробнее?
Что за подмена "прямо на лету" и почему этого нельзя сделать с таблицами?

[gl00mie]

Спасибо за информацию, но кое с чем не могу согласиться.

Цитата:

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

Так называемые AxBC-классы (с префиксом Ax) появились в AX 4.0 вместе с Axd-классами, как основа нового модуля AIF (Application Integration Framework).

По-моему, это AIF появился в 4.0, а AxBC-классы были и ранее, только использовались не в AIF, а в Commerce Gateway, т.е. как минимум они были уже в 3.0 (более ранние версии я не застал).

Цитата:

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

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

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

Цитата:

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

заметьте - AxBC-классы предназначены только для использования в AIF или InterCompany, больше нигде.

Опять же не могу согласиться. Если кто пробовал добавлять свои или модифицировать штатные обработчики modifiedField(), скажем, для шапки или строк заказов и ожидал увидеть в одноименном стандартном методе привычный switch(_fieldId), то его - опять же со времен 3.0 - ждал "сюрприз":

public void modifiedField(fieldId _fieldId)
{
    AxSalesTable    AxSalesTable;
    Object          formDataSource;

    super(_fieldId);

    if (this.isFormDataSource())
    {
        if (formDataSourceHasMethod(this.dataSource(),classstr(AxSalesTable)))
        {
            formDataSource = this.dataSource();
            AxSalesTable = formDataSource.AxSalesTable();
        }
    }
    else
    {
        AxSalesTable = this.AxSalesTable();
    }

    if (AxSalesTable)
    {
        AxSalesTable.setFieldAsTouched(_fieldId);
        AxSalesTable.modify();
    }
}

Этот код остался неизменным и поныне (AX 2009 SP1).

Цитата:

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

Что за подмена "прямо на лету" и почему этого нельзя сделать с таблицами?

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

[erudit]

Цитата:

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

Можно подробнее?
Что за подмена "прямо на лету" и почему этого нельзя сделать с таблицами?

gloomie, правильно отметил, примером может быть подмена кодов номенклатуры (ItemId) или клиента (CustAccount) везде где они используются, например классе AxSalesLine, см. методы parmItemId(), parmCustAccount(). У них везде есть код похожий на:

    if (this.valueMappingOutbound())
    {
        return this.axCustAccount(salesLine.CustAccount);
    }
    else
    {
        return salesLine.CustAccount;
    }

Что означает, если в данном документе, для данного поля таблицы (в примере вверху это SalesLine.CustAccount) настроен value mapping, то будет происходить подмена значений "на лету" всегда когда это поле будет использоваться системой (доступ к полям в AIF производится только используя parm-методы Ax-классов).

Цитата:

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

По-моему, это AIF появился в 4.0, а AxBC-классы были и ранее, только использовались не в AIF, а в Commerce Gateway, т.е. как минимум они были уже в 3.0 (более ранние версии я не застал).

Тут Вы 100% правы, AIF и Axd-классы появились в 4.0, а AxBС-классы были ещё в 3.0

Цитата:

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

Опять же не могу согласиться. Если кто пробовал добавлять свои или модифицировать штатные обработчики modifiedField(), скажем, для шапки или строк заказов и ожидал увидеть в одноименном стандартном методе привычный switch(_fieldId), то его - опять же со времен 3.0 - ждал "сюрприз":

Исключения, только подтверждают правила :-) Можно найти разные примеры использования AxBC-классов вне модулей AIF и InterCompany (как упомянутый Вами), но это будет скорее побочное применение, чем оригинальная задумка.

[mazzy]

Цитата:

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

подмена кодов номенклатуры (ItemId) или клиента (CustAccount) везде где они используются, например классе AxSalesLine, см. методы parmItemId(), parmCustAccount().

Только это?

Цитата:

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

Исключения, только подтверждают правила :-) Можно найти разные примеры использования AxBC-классов вне модулей AIF и InterCompany (как упомянутый Вами), но это будет скорее побочное применение, чем оригинальная задумка.

Хм. Тогда зайдем с другой стороны
Присоединюсь к Zabr и спрошу - а может где-нибудь есть документация для чего ax-классы сделаны и как с ним работать?

может я чего пропустил?

вот что есть на форуме

Цитата:

Сообщение от Blog bot

· AxBC (Ax) classes that provide an object API on top of the database tables referenced in the query.

Источник: http://blogs.msdn.com/dsiebold/archi...f-top-ten.aspx

Цитата:

Сообщение от Blog bot

Источник: http://feeds.feedburner.com/~r/Insid...lbase-api.html
==============

The goal for creating Ax classes was to have an API available when creating and updating records in Dynamics AX tables. The design goals of the AxInternalBase API were as follows:

• The API must be easy to use.
• The API must handle related fields. The default value should apply when a field is updated. For example, when you update the customer account field on the sales order, the address fields should be populated with default values when you copy the address fields from the customer record to the sales order record.
• The API must handle the sequence of field updating. For example, the invoice account field is a related field, which should revert to the default value when the customer account field is updated.
• Field value defaulting might not always provide the expected end result. Consider an example: If the invoice account field is updated first and related fields' values are defaulted, and then the customer account field is updated and its related fields' values are defaulted, the defaulted value would then overwrite the explicitly provided value in the invoice account field.
• The API must handle fetching numbers or identifiers from number sequences. For example, when you create a sales order, a sales order number must be fetched from a sales order number sequence. The business logic that handles this is implemented in these classes.

New Ax classes must inherit from the base class AxInternalBase. The AxInternalBase class keeps track of which methods have been executed to set a table field to a specific value.

а также
Как часто вы кастомизируете стандартные сервисы номенклатур. (!)
axStart: InfoPath with default AIF web services (!)
dax-lessons: 3 Clicks to generate AXBC code
dax-ideas: Creating a SalesOrder through .net applications or BC classes
parm-метод для AxBC-класса
Кастом поля и AIF
Preston.Larimer: Item import from CSV file made easy (Kinda)

а также по тегу axbc и тегу aif


=========================
и по прежнему остается вопрос: В чем преимущество ax-классов перед непосредственной работой с таблицами?

в ходе обсуждения выявлены следующие вкусности axbc-классов:
1. удобство для программиста для использования во внешних системах
2. автоматическая "подмена кода" в некоторых заранее прописанных местах
3. инструменты для генерации классов-оберток.

только в чем преимущество внутри Аксапты то?
Например, для работы с журналами внутри Аксапты есть:
= и непосредственная работа с таблицами через initFrom* и переопределение (overload) системных методов
= и классы JournalTableData, JournalTransData, journalStactic.
= и куча классов типа LedgerJournalTransUpdate* и даже локализаторское семейство LedgerJournalCreate*
= и классы LedgerJournalTransType в зачаточном состоянии (причем LedgerJournalTableType отсутствует)
= и axLedgerJournal*

Чуть проще для SalesTable. Есть:
= и непосредственная работа с таблицами через initFrom* и переопределение (overload) системных методов
= и SalesType*
= и axSalesTable

В чем преимущество каждого из подходов? Когда и какой применять?

[erudit]

Цитата:

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

Присоединюсь к Zabr и спрошу - а может где-нибудь есть документация для чего ax-классы сделаны и как с ним работать?

К сожалению, подтвердить свои слова публично доступной документацией не могу. Я много лет работаю с AIF, также общался с людьми из Микрософта которые создавали Axd-framework и AxBC-классы, на основе этого и мои выводы, но возможно я чего-то тоже не знаю.

[mifi]

Цитата:

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

К сожалению, подтвердить свои слова публично доступной документацией не могу. Я много лет работаю с AIF, также общался с людьми из Микрософта которые создавали Axd-framework и AxBC-классы, на основе этого и мои выводы, но возможно я чего-то тоже не знаю.

Навскидку - есть немного в тренинге по AIF (один параграф в Chapter 2). Может еще где-то есть более подробное описание, хотя в общем и этого достаточно для описания сути. Можно конечно, продолжать искать черную кошку в темной комнате, если "тривиальное" описание не устраивает пытливый ум Сам по себе тренинг интересен как вводный в AIF.
"AXBC CLASSES
Base classes, or AxBC classes, are classes that expose any table used within a document to the AIF framework. Each AxBC class require a specific set of methods. There are get and set methods for each field on the table – these methods are named parm<fieldname> and set<fieldname>. There are also methods to return the current record, to set the current record, to return an empty record, and to return an orig() record."

https://mbs.microsoft.com/customerso...alse&stext=aif development

[mazzy]

спасибо, erudit.

Цитата:

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

Можно конечно, продолжать искать черную кошку в темной комнате, если "тривиальное" описание не устраивает пытливый ум Сам по себе тренинг интересен как вводный в AIF.

mifi, вы упорно пытаетесь ответить не на тот вопрос.
и упорно уводите обсуждение в оффтопик.

повторяю вопрос:

Цитата:

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

и по прежнему остается вопрос: В чем преимущество ax-классов перед непосредственной работой с таблицами?

"тривиальное описание" не дает ответа на вопрос "чем лучше/хуже".
"тривиальное описание" не дает ответа на вопрос "когда именно эффективнее использовать одно, а когда именно другое".
что ж, спасибо хоть за информацию о том, что кроме "тривиального описания" пока ничего нет.