Какая польза от сервисного уровня в приложениях Spring Boot?

Question

Я новичок в Spring Boot и создаю RESTful API без пользовательского интерфейса.

Я думаю, стоит ли мне использовать бизнес-сервис и вызывать репозиторий оттуда или просто вызывать репозиторий непосредственно из моего контроллера REST

Answer 1

Сервисный уровень не является концепцией эксклюзивной от Spring Boot. Это программный архитектурный термин, который часто называют шаблоном. Простые приложения могут пропустить уровень обслуживания. С практической точки зрения, ничто не мешает вам вызывать метод хранилища из уровня контроллера.

Но я настоятельно советую использовать уровень обслуживания, поскольку он в первую очередь предназначен для определения приложения. границы. Обязанности уровня обслуживания включают (но не ограничиваются ими):

• Инкапсуляция реализации бизнес-логики;
• Централизация доступа к данным;
• Определение места, где начинаются транзакции /end.

Цитирование шаблона сервисного уровня из каталога Мартина Фаулера * Корпоративной архитектуры приложений :

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

Answer 2

Разделение интересов - это ключ:

• Контроллер (уровень представления или порт) - это интерфейс протокола, который предоставляет функциональность приложения в виде веб-сервисов RESTful. Следует к этому и не более того.
• Репозиторий (постоянный уровень или адаптер) абстрагирует постоянные операции: поиск (по идентификатору или другим критериям), сохранение (создание, обновление) и удалениезаписей. Должен к этому и ничего более.
• Сервисный уровень (домен) содержит вашу бизнес-логику. Он определяет, какие функции вы предоставляете, как к ним осуществляется доступ и что передавать и получать взамен - независимо от любого порта (из которых может быть несколько: веб-сервисы, очереди сообщений, запланированные события) и независимо от его внутреннегоработы (никто не заботится о том, чтобы служба использовала хранилище, или даже то, как данные представлены в хранилище). Уровень обслуживания может переводить 1: 1 из данных хранилища или может применять фильтрацию, преобразование или агрегацию дополнительных данных.

Бизнес-логика может начинаться с простого вначале и предлагать не более простых операций CRUD, но это не значит, что она всегда будет оставаться такой. Как только вам нужно разобраться с правами доступа, вам больше не нужно перенаправлять запросы от контроллера непосредственно в хранилище, а также проверять доступ и фильтровать данные. Запросы могут нуждаться в проверке и проверке согласованности перед обращением к базе данных, могут применяться правила и дополнительные операции, поэтому ваши службы со временем получают большую ценность .

Даже для простых случаев CRUD я быввести уровень обслуживания, который, по крайней мере, переводит из DTO в Entities и наоборот.

Сохраняйте свои контроллеры / репозитории (или порты и адаптеры) тупыми, а ваши службы умными, и вы получите удобное в обслуживании и проверяемое решение.