Нормально ли вызывать из Сервлета DAO и Service одновременно?

Question

[Biaci_Anj]

Пишу сервлетный проект, у меня сделано так, если методу нужно простое действие с БД -> вызывается ДАО.
Если нужно что-то серьезное ( сохранить фото, например ) -> сервис.
При этом сервис одной сущности вообще пустой, там ничего нет.

Нормально ли это? Или мне обязательно между сервлетом и дао делать прокладку в виде сервиса, которая просто делегирует все дела дао?

Answer 1

[Dmitry Roo]

Расскажу из личного опыта:
Мне всегда хочется, чтобы модель, которая используется в БД, и модель, которая используется в контроллере, были одной и той же моделью.
Все просто же: пришёл запрос в контроллер - сохрани в бд; нужно что-то из бд - сделай селект и отправь в контроллер.
Но никогда, ни разу это не было хорошей идеей.

Начнём с того, что как только появляется хоть какая-то вложенность объектов, никто в здравом уме не будет в контроллере передавать эти объекты, ограничиваясь ссылками на них, в лучшем случае (используя их id); закончим вопросами безопасности и консистентности данных, которые сразу, мимо валидации и какого-то сервиса отправляются в бд.

Отвечаю на ваш вопрос:
1. Всегда используйте сервис. Умение сохранять объекты в бд у контроллера противоречит принципу solid
2. Используйте луковую архитектуру. Доменная модель не должна ничего знать о внешних интеграциях.

Comments

[Михаил]

Поясню за "луковую архитектуру". Это означает что есть слой сервисов, который реализует бизнес-логику (даже если эта логика тупа на уровне "сохрани в БД, прочитай из БД" как это обычно происходит в CRUD-приложениях). И есть внешний для бизнес-логики мир. Так вот, бизнес-логика не должна зависеть от внешнего мира, наоборот, внешний мир должен прогибаться под бизнес-логику приложения.
А внешним миром тут является:
а) контроллер. Который может внезапно из REST превратиться в какую-нибудь Service Bus. Или RPC или еще во что-нибудь.
б) БД. Которая из реляционной может неожиданно стать NoSQL, обрасти каким-нибудь кэшированием, выделиться в отдельный микросервис и т.д.
Поэтому, строго говоря, в каждом слое должны быть свои модели (DTO) и конвертеры данных между ними. Разумеется, далеко не во всех проектах имеет смысл настолько вкладываться в "чистую архитектуру" (см. Р. Мартин "Чистая архитектура"). Но если нужен гибкий, тестируемый, повторно используемый код - то это хороший путь.