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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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