Знаю что Spring приложение разбивается на разные слои: Config( где лежат наши конфиги), DAO (для работы с БД), Model(наши данные, Pojo классы), Controllers( контроллеры) и service, в котором должна лежать бизнес логика. В одном проекте увидел такую картину: В DAO есть класс UserDAO который работает с БД и в Service есть класс UserService у которого есть поле UserDAO и он в точности копирует все методы UserDAO и внутри просто прописывает UserDAO.getUsers(); Затем данные идут в контроллер. Зачем нужен service в таких приложениях если он просто вызывает методы из DAO?
Здравствуйте!
Я обычно, использую не только service, но и service implementation, но можно обойтись и просто сервисом... все наверное зависит от сложности задачи.
А насчет реализации, да в сервисе прописывается бизнес логика... Я например, использую следующим образом...
все методы интерфейса repository реализую в сервисе. А можно сам сервис использовать, как интерфейс, а дальше создать serviceImpl и там реализовать методы...
Что касается DAO, то в сервисах вы можете хранить не просто геттеры и сеттеры, а например методы-конвертеры Entity в DAO и наоборот. А также всякие методы реализующие меппинг (ModelMapping) (если вам конечно же все это нужно)
Есть две основные причины появления "прозрачного сервисного слоя" в приложениях:
Потому что так принято. Автор делает примитивное приложение, которому вообще не нужна многослойная архитектура, но умные дяди говорят, что слои быть должны, и он вкорячивает слои ритуальные.
На вырост. В MVP в сервисный слой положить нечего, но развитая бизнес-логика предвидится в следующих версиях. Намного легче сделать пустой слой, а потом постепенно его наполнять, чем добавлять его потом в рабочий код.
Средний
