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

Question

По моему опыту, вот как использовались весенние контроллеры ive: Определите контроллер пружины, который возвращает значение некоторого типа в уровень представления. Метод сопоставления запросов контроллера вызывает сервисный уровень. Сам сервисный уровень состоит из интерфейса и реализации. Интерфейс службы всегда содержит только один метод, поэтому он не является полиморфным, поскольку он сохраняет «одну форму» последовательно. Реализация службы может обращаться к данным какого-либо типа, возможно, из DAO и возвращает контроллер. Контроллер может немного изменить эти данные, прежде чем вернуть их обратно на уровень представления.

Что это за пункт интерфейса в этом случае? Ive никогда не сталкивался с реализацией Spring сервиса, вызванной несколькими контроллерами, поэтому почему интерфейс?

Разве не имеет смысла использовать класс контроллера-помощника, который выполняет действия по реализации службы?

Answer 1

Использование Сервисного уровня выгодно, поскольку оно обеспечивает хорошее логическое разделение бизнес-логики от задач контроллера. В классе Service вы можете инкапсулировать бизнес-логику, связанную с определенным аспектом, например, PaymentService. В PaymentService вы можете реализовать различные методы, такие как cardPayment(), paypalPayment(), refund(). Различные контроллеры будут использовать одну единственную услугу. Кроме того, сервисный уровень также удобен для повторного использования кода.

Использование интерфейсов удобно, если позже вы решите использовать некоторые функции AOP, добавьте некоторую логику (например, журнал), между контроллером и сервисом, не меняя его код.

Answer 2

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

Answer 3

Вы правы - сервисный интерфейс, как правило, вариант использования конкретных, однако есть еще несколько хороших причин для создания интерфейса:

• Его просто хорошая практика. Например, он позволяет заменять новую реализацию сервиса. На самом деле нет никакой стоимости или негативного влияния на извлечение интерфейса через IDE.
• Позволяет использовать DynamicProxies для управления транзакциями, проблемами безопасности и т. Д. Динамические прокси-серверы быстрее, чем прокси-серверы cglib, и для них не требуется конструктор по умолчанию. , , Кроме того, в прошлом прокси на конкретных объектах иногда могли быть шелушащимися, но DynamicProxies настолько просты, что мало места для того, чтобы что-то пошло не так.
• Как отметил Люк Тейлор, это упрощает тестирование.

Answer 4

Я думаю, что интерфейс - это хорошая идея, потому что он позволяет вам поддерживать бизнес-логику в реализации и не беспокоиться о том, как вы открываете ее удаленно. Вы можете сделать интерфейс службой REST или SOAP, EJB или что-нибудь еще, что вам нужно. Получение данных и их отсутствие не меняют бизнес-логику. И он держит его полностью отдельно от контроллера. Вы можете использовать эту услугу за пределами веб-уровня.