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

[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

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