Здравствуйте, MadHuman, Вы писали:

MH>

MH>тем что, логика проверки аргумента arg1 довольно сложна (это не одна строчка для if как в упрощённом примере) и специфична именно для GetThing, и там уже реализована, тк функция используется не только для хандлера рест-апи ендпойнта.
Что мешает просто в отдельный метод вынести? Или даже в отдельный класс?
Я так понимаю, что основной это "уже там реализована",но это аргумент слабый, так как с современными средствами рефакторинга перемещение кода довольно простое, а других положительных эффектов нет


MH>в предлагаемом вами варианте логика проверки перенесена из GetThing в ProcApiRequest. это было бы ок, если она совсем простая, но она не совсем простая.
Это неважно, рефакторинг extract method выполняется легко.

MH>проверка внутри GetThing органична и реюзает часть внутренней логики. не так просто её взять и перенести.
Это ограничение, которое ты сам себе создал. Кроме того непонятно почему такая нетривиальная логика кидает в итоге ArgumentException, который по сути usage, а не runtime exception.

MH>и минус — в GetThing проверка всё равно нужно, т.к. GetThing не только для ProcApiRequest.
Вовсе не факт. У тебя в каждом методе АПИ своя валидация.

Чтобы руками не дублировать во пользуйся model binding и встроенной валидацией

MH>можно вынести логику валидации в отдельную функцию и реюзать и в GetThing и в ProcApiRequest, так будет уже лучше.
MH>но было ощущение что кэтчем эксепшина из GetThing тоже норм.
MH>не всегда хорошо чтоб каждое место использование функции вынуждало её менять/рефакторить.
А какая разница где код править, в котроллере или GetThing?

Если сценарий использования меняется, тоти сама функция меняется. Это называется "проектирование сверху вниз"