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

[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 (как упомянутый Вами), но это будет скорее побочное применение, чем оригинальная задумка.