пришлось мне возиться с одним проектом.. обычный такой вебсервис. апи база все дела.
так вот чел который его делал упорно избегал среднего слоя. и фигачил работу с репозиторием прям в контроллере. т.е. вызовы репозитория и какая то там логика была внутри контроллера.

я вот как то после спринга к такому не привык. но решил подумтаь. а так ли нужен в некоторых случаях сервисный слой, ведь в большинстве кейсов всё что ты делаешь в контроллере - вызываешь один единственный метод сервиса и все чудеса уже идут там.
что тогда в контроллере делать? та же валидация полученных данных она производится прямо внутри того класса который на входе в контроллер. что тогда делать в контроллере остается? ну логировать какие то мелочи ненужные и всё.

из минусов что вижу - у меня вознили проблемы с обкладыванием тестами. т.е. мне надо писать по-сути апи тест. чтоб проверить логику. и это как то не очень. опять же на мой взгляд.

в целом, мой консервативный взгляд говорит мне, что сервис-слой таки нужен. даже если в контроллере останется один единственный вызов.

собссно что думаете вы?

понятно. ну а всё же в той же экосистеме спринга что внутри то держать контроллера? ну окей может какой-нибудь диспетчер сервисов? если один эндпойнт отвечает за много чего.

PetroNotC SharpandreykaT,
Ну если у вас из БЛ один метод дайМнеХХХ(...
конечно сервис слой не нужен.
да. в том и вопрос. вроде бы и не нужен. а может всё же нужен??

вот сегодня он тебе не нужен а завтра стал нужен. и ты такой начинаешь копипастить весь код в сервис.

мне кажется, субъективно конечно же. это выглядит несколько неряшливо. но.. возвращаясь к изначальному вопросу. я так понимаю, это всё же практикуется и не говнокод.

можно подробнее? не совсем понял.

я как то был в проекте. там был кстати тоже вроде 4 эндпойнта и всё. остальное они рулили через кейсы. т.е. длиннющая портянка кейсов которая решала на какой сервис уходит запрос. но проект был на тот момент 10+ лет и наерное тогда писали только так :) не знаю чем мотивировали скажем использование этого вместо того чтоб создать новый контроллер с прописанным названием в пути. но вот было такое вот решение.