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

Question

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

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

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

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

Я также подумал: проверка. Я сделаю проверку моего Клиента в сервисе, но .... гораздо удобнее проверять в Sконтроллер вывода.

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

Answer 1

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

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

class Service {
  private DatabaseBarRepo barRepo;
  private DatabaseFooRepo fooRepo;

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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