Мне действительно нужен уровень сервиса?

Мое веб-приложение написано с помощью Spring MVC + Hibernate.

Моя модель - объект "Клиент" POJO.
У меня есть объект DAO "CustomerDAO", его метод "saveCustomer (c)" содержит код, взаимодействующий с Hibernate;
Затем я создал " CustomerService с помощью метода" saveCustomer (c) ", который просто передает объект-клиент дао для сохранения;
Наконец, есть "CustomerController" и customer.jsp, которые отвечают за уровень представления, поля формы jsp привязаны к объекту Customer на стороне контроллера. Контроллер вызывает службу.

Я видел, как много приложений следуют этой (лучшей) практике, но мне интересно, зачем мне нужен уровень сервиса.

Может быть, это полезно для развязывания цели: я могу показать универсальный фасад для контроллеров и ввести в сервис HibernateDAO, GaeDAO, MyDAO и т.д. Но я мог бы сделать это и без службы: используя интерфейс.

Я также утверждал: валидация. Я сделаю проверку своего Клиента в сервисе, но... это гораздо удобнее для проверки в контроллере Spring.

Помогите мне понять концепцию, пожалуйста:)

Ответ 1

Вам не нужен служебный уровень. Однако это поможет вам

Разделить компоненты
Вы можете применять определенные бизнес-правила на своем уровне обслуживания, которые должны быть агностическими для вашего репозитория.
Предоставить услуге фасад одного или нескольких репозиториев. Рассмотрим следующий пример

class Service {
  private DatabaseBarRepo barRepo;
  private DatabaseFooRepo fooRepo;

  @Transactional
  public void serviceRoutine() {
     barRepo.doStuff();
     fooRepo.doStuff();
  }
}

Здесь мы даем два отдельных репозитория, участвующих в одной транзакции. Это характерно для баз данных, хотя принципы применимы и для других систем.

Ответ 2

Ключом является транзакционное поведение. Если у вас нет уровня обслуживания, где вы будете демаркировать транзакции?

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

Кроме того, вы хотите, чтобы ваш уровень пользовательского интерфейса был как можно более простым, и бизнес-код (который иногда намного сложнее, чем суннит, называющий метод DAO), изолированный в определенных компонентах. Это позволяет

модуль тестирования уровня пользовательского интерфейса, издеваясь над уровнем обслуживания
блок тестирования уровня обслуживания (бизнес-кода) путем издевательств над уровнем DAO

Ответ 3

Прямо сейчас ваш сервисный уровень тривиален, потому что ваш сервис представляет собой тривиальную оболочку для доступа к базе данных. Это все приложение? Если нет, когда вы начнете создавать нетривиальные части, ваш уровень обслуживания будет расширяться.

Ответ 4

Вы можете сохранить многословие, указав BaseService, который имеет все операции CRUD, делегируя в него BaseDAO.

Помимо CRUD, почти все остальное имеет отдельную логику для бизнес-логики и для конкретных операций с базой данных. И еще одно: вы можете иметь транзакцию для нескольких операций с базой данных, аннотируя методы уровня сервиса с помощью @Transactional

Ответ 5

Есть другие вещи, которые вы на уровне сервиса. Когда-нибудь его о применении бизнес-правил, прежде чем передать какое-либо действие DAO. Иногда одной службе необходимо взаимодействовать с другими службами, DAO для требования бизнес-правил.

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