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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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