Сервисный уровень и контроллер: кто о чем заботится?

Question

В классе мы сейчас учимся создавать приложение Spring, хотя Spring не участвует напрямую, мы научились создавать интерфейсы для объектов DAO и сервисного уровня.

Пожалуйста, исправьте меня, если я ошибаюсь: слой DAO довольно абстрактный: он просто содержит операции CRUD и в дальнейшем используется для чтения данных (т. Е. Для получения всех объектов, получения определенных объектов и т. Д.)

Сервисный уровень: содержит сервисы для создания и удаления вещей, именно здесь должна быть бизнес-логика.

Теперь все это имеет смысл на уровне обслуживания;кроме «обновления» объектов.Вы просто поместили функцию «update», которая просто сохраняет объект в вашей базе данных?Или вам тоже нужно определить логику?Вот где мое замешательство таково, что я понимаю, что объекты в Spring - это просто POJO.Теперь кто проверяет данные?

Допустим, у меня есть объект "child", который имеет: Name, SurName, Gender, Photo, Birthdate поля.как бы я назвал услуги?Или вы просто позволите контроллеру позаботиться о проверке, что мне не кажется правильным.С другой стороны, было бы неправильным делегировать каждый установщик, который должен вызываться на сервисном уровне.

Так что в основном: помогите мне с определением сохранения ваших объектов через сервисный уровень.

Answer 1

Обычно сервис Spring является транзакционным.Вещи входят в определенный метод обслуживания, потому что они должны быть сгруппированы в одной транзакции.Если вы хотите извлечь объект из базы данных, перевернуть его и сохранить новую версию, поиск и сохранение должны выполняться одним и тем же методом обслуживания.Таким образом, ваши сервисные методы определяются в соответствии с тем, что вам нужно, чтобы приложение делало для пользователя.

Я пытаюсь ограничить контроллеры работой, связанной с проверкой параметров http, решая, какой сервисный метод вызывать с какими параметрами, чтоуказать в httpsession или запросе, какое представление перенаправить или переслать, или что-то подобное, связанное с Интернетом.

Что касается проверки: проверка входных параметров в контроллере - это хорошая вещь, чтобы быть уверенным, что никто не сможет сломать ваше приложение с помощью поддельных входов.Проверка в контроллере, как правило, сводится к тому, чтобы убедиться, что входные данные синтаксически исправны (включая обнаружение атак внедрения), тогда как проверка на уровне обслуживания заключается в проверке того, что состояние базы данных соответствует ожидаемому.

Таким образом, контроллеры содержат код инфраструктуры веб-фреймворка, а сервисы содержат код логики приложения.

Answer 2

Если вы хотите, чтобы контроллеры могли сохранять изменения в объекте Child, то традиционно у вас в службе будет метод с именем, похожим на ChildService.update(Child newchild), который будет обрабатывать вызов правильных DAO для сохранения новой версии. этого ребенка.

Контроллеры могут свободно запрашивать службу у Ребенка, изменять поля вокруг (возможно, на основе некоторого пользовательского ввода) - в рамках разумного проекта Контроллер должен выполнить некоторую работу с Ребенком POJO, а затем попросить Сервис сохранить изменения. , Модель POJO не должна ничего знать о контроллере, сервисе или DAO, а просто хранить данные, как вы предлагаете, - конечно, вы не захотите, чтобы каждый вызов setName() или setGender() автоматически приводил к обновлению базы данных.

Вместо этого контроллер и / или служба должны получить объект Child, выполнить любую необходимую ему работу с объектом в его единице работы, а затем попросить службу (а затем DAO) сохранить изменения.

Проверка может выполняться в несколько слоев - Контроллер может захотеть проверить любой ввод от веб-пользователя, а Служба может захотеть проверить, что у него есть действительный объект Child, прежде чем он сохранится. Особенно имеет смысл иметь некоторый уровень проверки на обоих уровнях на случай, если вы захотите повторно использовать эту Службу в других мощностях, таких как предоставление интерфейса REST, другой интерфейс и т. Д.