Я не уверен, что это действительно ответ, но это слишком долго для комментария.
Я думаю, что было бы бесполезным думать о MVC как о слишком жестком.Исторически это возникло (НАМНОГО раньше, чем большинство людей знают) как разделение интересов.Эта парадигма предшествует сети как минимум на 10 лет.
Когда у устройств конечного пользователя появилось достаточно мозгов, чтобы выполнять полезную работу, стало очевидно, что только потому, что ваш компьютер (не совсем тупой терминал) может хранить программный код, он былне то место, откуда можно звонить из базы данных и отправлять результаты.Одно из первых клиент-серверных приложений, которое я когда-либо видел, было одной из его проблем роста - блестящая идея загрузить всех возможных клиентов в список выбора на бездисковой рабочей станции Unix.К сожалению, этот список клиентов был более 100 000 записей.Излишне говорить, что это не сработало.
Самым первым разделением интересов, о котором я знаю, была философия IBM, восходящая к середине 1980-х годов.Каждая часть приложения в 2-х или 3-х уровневой модели была разделена на отдельные сервисы, которые можно разделить.Это были:
- Служба презентаций (также известный как View)
- Служба приложений (общие служебные функции)
- Логика приложения (также известный как Domain; он же Controller)
- Манипулятор данных / Контроллер состояния данных (он же модель)
Удивительно, что под солнцем так мало новых идей.Имена меняются.Понятия не.Главное, чего не хватает в приведенном выше списке, это интерфейс SERVICE (он же Spring @Service).Они еще не очертили четкие точки входа в логику приложения.Кроме того, Служба приложений потеряла свое внимание при вызове и просто вернулась в папку UTIL, где она, вероятно, принадлежит.
Что касается вашего вопроса, по умолчанию @Configuration - это Controller of MVC.Не потому, что другие ноги могут стоять сами по себе, они не могут.Но поскольку это, очевидно, не модель или представление.
Возможно, вам будет полезно прочитать о Spring PRE Spring Boot.Лично мне очень не нравится Spring Boot.Это слишком далеко от ИМО, чтобы отказаться от контроля над окружающей средой.
Есть действительно интересные (по крайней мере, мне) вещи, которые нужно знать о множественных контекстах и родительских и дочерних отношениях.Это больше, чем просто академическое упражнение, если вы правильно структурируете свои модели и контроллеры отдельно от ваших элементов просмотра.
Мне также нравится использовать Spring Profiles для замены Oracle и H2, чтобы тесты могли проходить в течение нормальной продолжительности жизни человека.Не говоря уже о повторяемости, что прямой доступ к базе данных почти наверняка нет.