Служба предназначена для представления фасада пользователю, который предоставляет бизнес-функции, которые пользователь может выполнять. По сути, если у вас есть набор низкоуровневых сценариев использования, методы службы будут соответствовать отдельным действиям пользователя. Услуги являются транзакционными, обычно, если пользователь делает что-то, мы хотим, чтобы все последствия этого действия были зафиксированы вместе. Разделение между контроллером и службой означает, что у нас есть одно место для размещения специфичных для веб-приложений функций, таких как получение параметров запроса, проверка и выбор места для переадресации или перенаправления, а также отдельное место для размещения бизнес-логики - вещи, которые не зависит от веб-приложения API и о том, какие объекты обновляются с какими значениями и сохраняются, используя какие объекты доступа к данным.
Я вижу много случаев, когда люди думают, что им нужен один сервис для каждого дао. Я думаю, что они предполагают, что, поскольку объекты доступа к данным, а также контроллеры и модели достаточно механичны в отношении того, как они определены, сервисы должны быть одинаковыми, и они конструируют их безотносительно к реализуемым вариантам использования. Что происходит, в дополнение к большому количеству бесполезного стандартного кода службы, вся бизнес-логика заканчивается в контроллере, перепутанном с веб-специфическим кодом, и контроллеры становятся большими и неуправляемыми. Если ваше приложение очень простое, вы можете обойтись этим на некоторое время, но оно дезорганизовано, его сложно протестировать, и, как правило, это плохая идея. Мы должны стремиться к разделению проблем, хранению кода инфраструктуры в одном месте и бизнес-кода в другом, и правильное использование сервисов очень помогает в достижении этого.