[CodeStyle] check* vs validate* методы. в чем разница в X++? какой будет выводить в инфолог?

[sukhanchik]

Цитата:

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

А у тебя check-методы могут вызываться не из validate?

Конечно. Я же привел пример наличия кнопки "Проверка". validate - это некое событие в алгоритме, по результатам которого отрабатывает основной код (например, разноска).

Цитата:

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

И что насчет инфолога? ты допускаешь, что все они могут что-то выводить в инфолог?

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

Цитата:

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

и что насчет диалога с пользователем? Ну, этот пресловутый Book_RU.validateDelete?

Здесь у меня однозначный подход - все проверки должны выполняться до начала транзакции и все диалоги с пользователем должны быть выполнены с помощью стандартных форм системы, после чего в алгоритм должен быть передан ответ пользователя (в виде отдельного параметра). Опять-таки, оговорюсь, что все это не касается уже существующего фреймворка, т.е. даже если я не согласен с построением кода в Book_RU.validateDelete я не кидаюсь его переписывать, а пытаюсь построить код "в стиле", который был заложен его разработчиками. Но как только я ухожу от уже существующего кода - то я уже могу освободиться от этих "кандалов" в виде ранее написанного кода (и это необязательно касается стандартного кода - это касается любого кода, с которым мне приходится знакомиться).

Вообще - тут сложно вырабатывать какие-то правила - слишком сильно реализация зависит не только от бизнес-задачи, но и от места выполнения проверки.

Пример 1. Разноска товарного расхода. Проверка необходимого в наличии количества выполняется до резервирования, но если резервирование уже прошло, то нет смысла проверять необходимое количество в наличии - оно гарантированно будет - в этом смысл резервирования.

Пример 2 (AX2012). Проверка достаточности бюджетных средств. Если не используется функционал резервирования бюджета (который привязывает резерв к документу) и разносимый документ не указан в настройках контроля бюджета, то по сути бюджет может "пропасть" в любой момент, а значит его есть смысл регулярно проверять.

Пример 3. Аналог примера 2, только речь идет про проверку на закрытость периода. Конечно период могут закрыть в любой момент, но все же нет смысла проверять закрытость периода условно при любом изменении нашей "заявки на покупку", потому что это для пользователя не столь важно, как, к примеру, неожиданная "потеря" бюджета.

Я намеренно остаюсь в приведенных ранее мною примерах проверок, чтобы не распыляться.

В общем - общая идея такова, что в некотором алгоритме всегда есть проверки, которые можно выполнять на любом этапе алгоритма, а есть проверки, которые есть смысл выполнять только на определенных этапах. Но в любом случае - мне нравится идея выделять всевозможные проверки в методы с префиксом check*, а уже вызывать из методов validate* только те проверки, которые необходимо выполнить именно в данном validate*. Я также понимаю, что одна и та же проверка может быть вызвана как программно несколько раз (из нескольких validate*), так и условно вручную по нажатию специальной кнопки.