Исправление dimuska139, (текущая версия) :
Не знаю конкретно про Spring, но вообще такое разделение на слои абстракции очень удобно.
Entity - простой класс с геттерами и сеттерами без каких-либо других методов. Его можно гонять по всему приложению и не бояться, что кто-то из разрабов попробует вызывать метод save в каком-нибудь, скажем, форматтере. Потому что Entity не завязан на базу данных, метода Save у него нет, и это просто класс, а не Active record.
Repository - абстракция для хранения данных. И все запросы в базу только там. Нужна работа с другой СУБД - делаешь новый Repository, реализующий тот же интерфейс, но уже с кодом для работы с другой СУБД.
Service Layer - все ясно, уже писал выше.
Удобно тут то, что я могу без проблем покрыть юнитами, скажем, Service Layer. То есть я пихну туда Mock-объект репозитория и все - и не надо мокать ORM-ку. Если я захочу покрыть тестами контроллеры, то пихну туда Mock-объекты нужных мне сервисов, и не придется мокать какие-то внезапные запросы в базу и т.п. Потому что контроллеры взаимодействуют только с сервисным слоем.
Кроме того, все Entity можно вынести в отдельную библиотеку и юзать в других веб-приложениях, которые взаимодействуют с этой же базой данных.
Исправление dimuska139, :
Не знаю конкретно про Spring, но вообще такое разделение на слои абстракции очень удобно.
Entity - простой класс с геттерами и сеттерами без каких-либо других методов. Его можно гонять по всему приложению и не бояться, что кто-то из разрабов попробует вызывать метод save в каком-нибудь, скажем, форматтере. Потому что Entity не завязан на базу данных, метода Save у него нет, и это просто класс, а не Active record.
Repository - абстракция для хранения данных. И все запросы в базу только там. Нужна работа с другой СУБД - делаешь новый Repository, реализующий тот же интерфейс, но уже с кодом для работы с другой СУБД.
Service Layer - все ясно, уже писал выше.
Удобно тут то, что я могу без проблем покрыть юнитами, скажем, Service Layer. То есть я пихну туда Mock-объект репозитория и все - и не надо мокать ORM-ку. Если я захочу покрыть тестами контроллеры, то пихну туда Mock-объекты нужных мне сервисов, и не придется мокать какие-то внезапные запросы в базу и т.п. Потому что контроллеры взаимодействуют только с сервисным слоем.
Исходная версия dimuska139, :
Не знаю конкретно про Spring, но вообще такое разделение на слои абстракции очень удобно.
Entity - простой класс с геттерами и сеттерами без каких-либо других методов. Его можно гонять по всему приложению и не бояться, что кто-то из разрабов попробует вызывать метод save в каком-нибудь, скажем, форматтере. Потому что Entity не завязан на базу данных.
Repository - абстракция для хранения данных. И все запросы в базу только там. Нужна работа с другой СУБД - делаешь новый Repository, реализующий тот же интерфейс, но уже с кодом для работы с другой СУБД.
Service Layer - все ясно, уже писал выше.
Удобно тут то, что я могу без проблем покрыть юнитами, скажем, Service Layer. То есть я пихну туда Mock-объект репозитория и все - и не надо мокать ORM-ку. Если я захочу покрыть тестами контроллеры, то пихну туда Mock-объекты нужных мне сервисов, и не придется мокать какие-то внезапные запросы в базу и т.п. Потому что контроллеры взаимодействуют только с сервисным слоем.