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

[Maximin]

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

Цитата:

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

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

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

[mazzy]

Цитата:

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

Существующая реализация AIF такое поле уже перезаписать штатной обработкой не сможет, setField, вызываемый в процессе обработки записи, не будет записывать уже единожды записанное поле.

О_о!
Какие рекомендации по использованию?
я так понимаю, что стиль initFrom можно объявлять legacy и по возможности использовать axBC. так?

Можно ли попросить соображения в стиле: при таких то случаях лучше делать так?...

[gl00mie]

Цитата:

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

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

А можно пример такой ситуации с реальной таблицей и реальным полем, если только это не фин.аналитика? Изначально, как пишется везде в руководствах, задача AxBC-классов - подтягивание значений по умолчанию для одних полей в зависимости от тех или иных комбинаций значений других полей, заданных "извне". Если в заказе выбирается "счет на", то по нему можно автоматом подтянуть значение кода клиента, но если оно уже задано "извне", то нечего его перезатирать - это просто не входит в обязанности AxBC-классов. Если кто-то указал "неверное" значение поля, то это его право, но вылавливаться это должно на уровне validateField() или validateWrite(), а никак не на уровне класса, который должен подтягивать значения по умолчанию. Да, при импорте данных возникает сложность с тем, чтобы отличать, скажем, пустое значение и "отсутствие значения" (т.е. ситуацию, когда значение поля не надо задавать "извне", чтобы тот же AxBC-класс мог подтянуть корректное значение), но это уже немного другая тема. В том же .NET-е вполне себе справляются с такими ситуациями, успешно различая, когда задано пустое значение параметра и когда значение параметра "отсутствует".

Цитата:

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

Так, забавна ситуация, когда в пришедшей по AIF записи какое-либо из полей заполнено неправильно (т.е. значение-то корректное, но в сочетании с другими полями - нет). Существующая реализация AIF такое поле уже перезаписать штатной обработкой не сможет, setField, вызываемый в процессе обработки записи, не будет записывать уже единожды записанное поле.

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