16.11.2019, 06:37 | #1 |
Участник
|
Best Practice in real life: SysPolicy form as a bad example
Источник: http://alexvoy.blogspot.com/2019/11/...syspolicy.html
============== Источник: http://alexvoy.blogspot.com/2019/11/...syspolicy.html
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
18.11.2019, 13:29 | #2 |
Участник
|
Я что-то не понимаю пафоса. А где здесь криминал?
validateWrite() нужна в том случае, если нет уверенности в корректности заполнения полей. Обычно это происходит в случае, если поля заполняются пользователем. Он вполне может забыть что-то указать или указать не корректно А здесь-то совсем другой случай. Все ключевые поля заполнены. Ну, и зачем "лишние" проверки? Нет, я понимаю, что если выполняется кастомизация и в validateWrite() добавили некую проверку, которую ожидали при любом добавлении записи. То, да, такой код - это "сюрприз". Но, при чем здесь Best Practices? Это проблемы разработичка или консультанта/тестера. Смотря кто пропустил такую ситуацию. Вы же не настаиваете на выполнение validateField() для каждого поля, хотя там тоже много чего можно изменить. Или тоже необходимо?
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
18.11.2019, 13:58 | #3 |
Участник
|
Цитата:
Я для такого обычно использую следующий метод X++: public static void validateWriteRecordCheck(Common _record) { if (! _record.validateWrite()) { throw error(strFmt("Failed to write %1 table", tableId2pname(_record.TableId))); } } |
|
18.11.2019, 14:47 | #4 |
Участник
|
Именно потому, что это программное создание строки без участия пользователя. Т.е. здесь нет "внешних" данных, которые мог бы подготовить пользователь и в которых могла бы вкрасться ошибка. Все данные готовит разработчик. И, естественно, они должны быть корректными. У Вас это в релиз не пройдет, если что-то не заполнено. Ну, это все-равно, что проверять тип переданного в метод параметра, при том, что он указан явно в EDT. А вдруг не то передали?
Ну, представим, что добавили validateWrite() и он вернул false. Что в этой ситуации может сделать пользователь? Да ничего! Запись же программно создается. Получаем "мертвый" код, который вообще не может быть использован. Нет, я понимаю, почему хочется поставить validateWrite(). Сам иногда это делаю. А вдруг?!. Но в данном конкретном случае - это явный over-programming. Не вижу никакого криминала, если в описанном сценарии этой проверки нет
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
18.11.2019, 14:58 | #5 |
Участник
|
Почему ничего - он зарепортит ошибку. Ошибочная запись создана не будет. Могут кстати и не только добавить validateWrite, но и добавить обязательное поле, которое тут не заполняется
|
|
18.11.2019, 15:22 | #6 |
Участник
|
Т.е. пользователь выступает как тестер? Разработчик разрабатывает "не глядя" и не тестируя. А тестер - это лишняя профессия... Ну, поздравляю. Вот и Вы, наконец, поняли позицию Microsoft
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
18.11.2019, 22:25 | #7 |
Участник
|
Цитата:
Сообщение от trud
Откуда вы знаете что все ключевые поля заполнены? Для этого и нужен validateWrite, который собственно это проверит.
Я для такого обычно использую следующий метод X++: public static void validateWriteRecordCheck(Common _record) { if (! _record.validateWrite()) { throw error(strFmt("Failed to write %1 table", tableId2pname(_record.TableId))); } }
__________________
Felix nihil admirari |
|
18.11.2019, 22:27 | #8 |
Участник
|
согласно рекомендациям, с коими я согласен, фраза должна строиться от противного:
validateWrite() не нужна лишь в том случае, если...
__________________
Felix nihil admirari |
|
18.11.2019, 23:33 | #9 |
Участник
|
Хорошо. В данном случае она нужна? Почему?
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
18.11.2019, 23:37 | #10 |
Участник
|
А как вы делаете? Владимир Максимов как я понял предлагает вставлять невалидную запись, ибо пользователь на ошибку все равно не сможет среагировать. По мне так странный подход |
|
18.11.2019, 23:50 | #11 |
Участник
|
Да с чего Вы взяли, что запись не валидная? Вот можете внятно объяснить?
У вас запись из кода и дат. Код вставили. Даты вставили. Зачем еще раз проверять факт наличия этого самого кода и дат? Кастомизация? А Вы что, не будете править код создания если, скажем, новое поле добавите? Переложите бремя тестирования на пользователя? Вы программно, подчеркиваю еще раз - программно(!), готовите данные для новой записи. Если Вы "вменяемый" разработчик, то вы обязаны подготовить эти данные корректно. С тем, чтобы validateWrite() прошел без ошибок. Но если Вы изначально готовите данные корректно, то зачем Вам себе перепроверять? Или Вы предполагаете, что можете подготовить не корректные данные. А зачем это делать?
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
18.11.2019, 23:58 | #12 |
Участник
|
Корректно это понятие во времени. Сегодня корректно, а завтра некорректно. Т.е. установите вы какое-нибудь решение к примеру, где добавлят обязательное поле. Заполнять его будут в initValue(), которого тоже тут кстати тоже нет.
Сейчас модно использовать RSAT для тестирования. Без принудительного вызова validateWrite() все тесты пройдут, ошибку заменят только впоследствии |
|
|
За это сообщение автора поблагодарили: wojzeh (1). |
19.11.2019, 00:27 | #13 |
Участник
|
Т.е. алгоритм такой
1. Сделали кастомизацию 2. Программный код создания записи не исправили по этой кастомизации, т.е. он стал не корректным 3. Тестировать "как положено" не стали 4. В релизе ValidateWrite отловит эту ошибку. Пользователь работать не сможет. Выставит bug-report разработчику Т.е. сам по себе код создания не корректный. А ValidateWrite нужен для того, чтобы переложить бремя тестирования на пользователя. Ну, тоже стратегия. Все как у Microsoft. С чего, собственно, я и начал...
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
19.11.2019, 00:37 | #14 |
Участник
|
именно о том и был мой исходный пафос, что рассуждать мы (девы) должны так:
в данном случае она НЕ НУЖНА, ПОТОМУ ЧТО а в большинстве случаев мы ставим валидацию перед записью. comme il faut, о котором ещё пушкин а.с. писал нам из прошлого в будущее
__________________
Felix nihil admirari |
|
19.11.2019, 00:39 | #15 |
Участник
|
Цитата:
делаем вроде такого MyTable t; t.Field1 = 1; t.Field2 = 'Test'; if (t.validateWrite()) { t.insert(); } else { error('something went wrong'); }
__________________
Felix nihil admirari |
|
19.11.2019, 00:43 | #16 |
Участник
|
Цитата:
простой пример: программно пишем дату, которую получили через параметры. она из прошлого, а мы по логике допускаем только даты из будущего. ну и так далее. в моём конкретном случае, мне нужно написать extension для проверки дупликатов. было бы написано, как доктор прописал, щас бы уже всё работало, так - делаем выкрутасы.
__________________
Felix nihil admirari |
|
19.11.2019, 01:31 | #17 |
Участник
|
Я написал, тестируем RSAT, в моем варианте он поймает исключение, в вашем варианте вставится некорректное значение, никто этого не заметит
X++: error('something went wrong'); |
|
19.11.2019, 02:40 | #18 |
Участник
|
Цитата:
Твой же пример со статическим вызовом буферного метода и генерацией исключительной ситуации противоречит данной рекомендации, но было бы интересно взглянуть, как ты его используешь на конкретном примере.
__________________
Felix nihil admirari |
|
19.11.2019, 17:44 | #19 |
Участник
|
Цитата:
Цитата:
Но в примере, который послужил основанием для дискуссии, "внешних" данных нет вообще. Нечего проверять-то... Цитата:
- Делать проверку на возможный дубликат до вызова метода создания - Если есть дубль, то менять данные с тем, чтобы дубля не было при создании новой записи Это так, первое, что в голову пришло. Но могут быть и другие варианты. Причем я не удивлюсь, если позже Вам придется добавлять в ValidateWrite() параметры для того, чтобы исключить ту или иную проверку...
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
19.11.2019, 18:00 | #20 |
Участник
|
Цитата:
PS: Что такое RSAT? Автотесты что-ли?
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|