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

[Maximin]

Эх, интересное обсуждение прошло мимо в угаре работы...
Вставлю свои 5 копеек и попробую ответить на этот вопрос:

Цитата:

Т.е. можно ли использовать initFrom из axBC-классов? и наоборот, можно ли использовать axBC из InitFrom?
какие ограничения? при каких условиях это допустимо, а при каких нет?

В качестве продолжения идей, описанных gloomie (я полностью согласен с ним), считаю, что старый подход initFromxxx стоит использовать в процессе рефакторинга и "разрыва" порочной практики их использования и только из самих axBC в качестве готовых "наборов" для инициализации каких-то полей. Другое дело, что делать этот рефакторинг и переработку достаточно эффективно, и не думая о проблемах последующей миграции на новую версию/обновление, может только сам вендор (aka Microsoft). Так что для разработчиков, работающих уже на конкретной версии системы, думаю, стоит ограничиться "нераспространением зла" и использованием только нового API, не трогая legacy.

Далее. Расписывая прелести axBC, gloomie не счел достойным упомянуть, что при реализации конкретной необходимой функциональности, стройное дерево зависимостей инициализации полей, одну ветку из которого нарисовал mazzy, зачастую начинает обретать петли. Так бывает, когда задача ставится таким образом, что для окончательного определения значений конкретного поля, приходится сделать один "оборот" по такой петле, порой, даже насильственно перезаписывая уже единожды заполненное поле. А раз так - то прозрачная схема метода setTableFields уже становится не такой уж и прозрачной, Так, забавна ситуация, когда в пришедшей по AIF записи какое-либо из полей заполнено неправильно (т.е. значение-то корректное, но в сочетании с другими полями - нет). Существующая реализация AIF такое поле уже перезаписать штатной обработкой не сможет, setField, вызываемый в процессе обработки записи, не будет записывать уже единожды записанное поле.