Код в примерах не разу не работал с http, даже есши бы нужно было бы работать с сессией я бы выделил бы какой-то ISessionStoeage и работал бы через него, дабы не обращаться к HttpContext или еще каким-то зависимостям фреймворка
Я считаю что подход уже не актуален, и мы шарперы вообще не любим вылазить за сам C#, потому всегда используем возможность не писать код на чем то другом. Пример попытки WebForms, Blazor, .razor файлы
Я предпочитаю тестировать чистые функции, для этого я пишу в сервисах код который оборачивает их и используя репозитории и тд дает данные чистым функциям, я просто в статье эту тему не поднимал. А на счет httpcontext и моков, лучше тестить чистые функции, а все остальное end2end, так вы действительно проверите весь флоу.
В последнее время я изучаю дополнительно ФП, и мой код уже поменялся как раз в эту сторону.
Я пишу логику в отдельных чистых функциях, они работаю только с данными, а эти функции уже использую в сервисе дабы описывать UseCase и дать этим функциям те данные которые им нужны.
Я никогда так API не пишу.
Всегда принимаю модель, возвращаю модель.
По умолчанию всегда 200\201 код, исключения ловит exceptionHandler который может поставить другой код в зависимости от типа ошибки.
Все такие вещи настраиваю немного выше, ведь у меня есть пайплайн
Контроллер нужен для того, чтобы преобразовывать HTTP-запрос в POCO и вызывать метод сервиса/команду, а затем возвращать результат в виде HTTP-ответа
Это он все делает сам, и код мы этот даже не видим. Мы уже достаточно хорошо абстрагировались от самого HTTP, но в принципе как я сказал, если у вас есть код для работы с вьюшками, или как вы сказали с http кодами и тд, то конечно стоит отделить контроллер и логику.
Я пишу такие API где принимаю модели и возвращаю модели, любые исключение ловит ExceptionHandler, то-есть все либо пройдет хорошо, либо вылетит в 500 ошибкой.
Если тип исключения домменный, то есть мой, я вывожу его пользователю
CTRL + M + L
Код в примерах не разу не работал с http, даже есши бы нужно было бы работать с сессией я бы выделил бы какой-то ISessionStoeage и работал бы через него, дабы не обращаться к HttpContext или еще каким-то зависимостям фреймворка
Да, именно это хотел донести, спасибо! :)
Если вы гиузите файл то в параметрах метода появится модель IFormFile, и в ней уже будет и файл, и имя, и тип
Я считаю что подход уже не актуален, и мы шарперы вообще не любим вылазить за сам C#, потому всегда используем возможность не писать код на чем то другом. Пример попытки WebForms, Blazor, .razor файлы
Я предпочитаю тестировать чистые функции, для этого я пишу в сервисах код который оборачивает их и используя репозитории и тд дает данные чистым функциям, я просто в статье эту тему не поднимал. А на счет httpcontext и моков, лучше тестить чистые функции, а все остальное end2end, так вы действительно проверите весь флоу.
В последнее время я изучаю дополнительно ФП, и мой код уже поменялся как раз в эту сторону.
Я пишу логику в отдельных чистых функциях, они работаю только с данными, а эти функции уже использую в сервисе дабы описывать UseCase и дать этим функциям те данные которые им нужны.
Всегда принимаю модель, возвращаю модель.
По умолчанию всегда 200\201 код, исключения ловит exceptionHandler который может поставить другой код в зависимости от типа ошибки.
Все такие вещи настраиваю немного выше, ведь у меня есть пайплайн
mediator.Send — опять таки простая прокся к нашей настоящей логике
Это он все делает сам, и код мы этот даже не видим. Мы уже достаточно хорошо абстрагировались от самого HTTP, но в принципе как я сказал, если у вас есть код для работы с вьюшками, или как вы сказали с http кодами и тд, то конечно стоит отделить контроллер и логику.
Я пишу такие API где принимаю модели и возвращаю модели, любые исключение ловит ExceptionHandler, то-есть все либо пройдет хорошо, либо вылетит в 500 ошибкой.
Если тип исключения домменный, то есть мой, я вывожу его пользователю
Флоу регистраци
Флоу авторизаци и тд