Какова наилучшая практика для реализации общих методов между контроллерами упора пружины?

Question

Я использую контроллер покоя пружины для реализации моего веб-API, я хочу поместить мои общие методы между контроллерами в одном месте, чтобы их можно было использовать во всех моих контроллерах.

Если нет возможности расширить @RestController аннотация, это хорошая практика писать общие методы контроллера в родительском классе BaseController и расширять все мои контроллеры из него?

Answer 1

Вы могли бы создать свой собственный стереотип / аннотацию , но это явно было бы непроизводительно, если вы хотите добавить только некоторые общие методы для контроллеров.Кроме того, вы сделаете свой код менее «весенним стандартом».Я не думаю, что ты этого хочешь.

Полезно ли писать общие методы контроллера в родительском классе BaseController и расширять из него все мои контроллеры?

Не думаю, что этоплохая практика, но здесь некоторые сценарии, где я не хочу использовать наследование классов для контроллеров:

• Общий код выглядит как логика, в то время как контроллеры должны выполнять не логику, а делегирование.Если они создают слишком много вещей, представьте класс обслуживания и делегируйте его.
• если контроллеры не разделяют набор общих полей / зависимостей / инициализаций, использование класса зависимостей, предоставляющего общие методы, вероятно, будет более понятным / простым.Создание иерархии классов, чтобы избежать объявления общего поля, кажется слишком сложным, и злоупотребление подклассами.
• Вы должны предпочесть Spring AOP и ControllerAdvice для общей обработки в контроллерах для предварительной / про / обработки и обработки исключений.

Если вы не попадете в эти случаи, да, абстрактный класс для ваших контроллеров выглядит хорошей идеей.

Answer 2

Моим контроллерам требуются общие функциональные возможности, такие как -инспектирование параметров входящих запросов и -включение заголовков в исходящем ответе.

Чтобы избежать шаблонов родительских / дочерних контроллеров, вызывающих друг друга, я воспользовался весенними аннотациями /hooks.

Для анализа и проверки параметров запроса я прошел маршрут класса рекомендаций контроллера и аннотировал там метод с помощью @ModelAttribute - который вызывает весной перед методами маршрута и - который можно использовать, чтобы сделать объекты доступными вмодель.

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

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

Answer 3

Если я правильно понимаю, вам нужен сервисный слой .Он может использоваться для хранения всей вашей бизнес-логики и общих методов, которые вам могут понадобиться.Вы извлекаете их и внедряете объект службы в свой контроллер.Оттуда вы просто вызываете свои методы из сервисного уровня и не загрязняете ваш контроллер.По моему опыту, это хорошая практика.

Еще одна вещь, которую вы могли бы сделать для методов, которые могут использоваться для различных типов контроллеров, не имеющих ничего общего, как вы сказали, может быть извлечена дляСервисный класс.Вы можете заполнить этот класс статическими методами, которые вы можете использовать в своем приложении.