Comments 11
Я бы порекомендовал для затравки статьи описать проблему которую вы решили применением данного решения. Пока ценность только в отказе от спринга.
Ценность, очевидно, в том, что пропадает гвоздями прибитая зависимость на спринг дату. И при необходимости его можно спокойно выкинуть, не меняя контракт внешнего взаимодействия. В целом подход правильный и его нужно придерживаться, если приложение не голый CRUD.
Ради строчки в импорте? Какой такой необходимости ? Будет необходимость выкинуть напишешь новую дтошку тогда когда оно действительно надо будет в не сейчас на это время тратить и архитектуру усложнять ради следования каким то правилам из книжки.
Если зависимость на Spring Data считается несущественной, то по этой логике можно и JpaRepository напрямую в контроллер передавать.
Но тогда теряется изоляция слоёв, а тестирование бизнес-логики без Spring-контекста становится заметно сложнее.
Помните тот веселый советский мультик? Там мальчик постоянно повторял - а, и так сойдет! В общем в конце он очень раскаялся.
Спасибо за замечание! Упустил некоторые моменты как само собой разумеющиеся. Правки внёс.
От Spring отказываться никто не призывает — это отличный контейнер и де-факто стандарт. Но минимизировать его влияние на внутреннее устройство системы — это уже другой вопрос.
PageQuery, PageResult и SortRequest живут в слое приложения.
Слой приложения - это набор use case, которые ничего о пагинации не должны знать. В этом основная проблема. Если рассмотреть простейшую архитектуру приложения с визуальным интерфейсом presentation layer -> use case -> persistence layer, то для presentation layer и persistence layer нужны данные пагинации и их надо пробрасывать из presentation layer в persistence layer. Но в этой схеме промежуточное звено use case заточено на бизнес-логику и ничего вообще не должно знать о пагинации. Поэтому приходится идти на не совсем правильные решения и пробрасывать пагинацию через use case.
JPA интерфейсы тоже не желательно использовать в слое приложения? Просто абстрация на абстрации получается. Где золотая середина?
Слой приложения обращается к DAO объектам слоя persistence layer. JPA интерфейсы лежат ниже DAO объектов. DAO объекты обращаются к базе данных, используя JPA интерфейсы.
JPA интерфейс - это ДАО обьект который должен жить в слое персистентности (инфраструктуры).
Чтобы обеспечить изоляцию инфраструктурного слоя (с целью недопущения прямого использования в сервисе или контроллере методов JPA интерфейса) между ним и сервисом в слое персистентности делают адаптер в который включают медоды позволенные к использованию.
Такой адаптер реализует интерфейс ДАО или доменный.
У JPA интерфейса и адаптера видимость пакетная (без модификатора паблик).
А сервис работает с интерфейсом ДАО.
Такой дизайн позволяет менять реализацию базы данных и осуществлять фейковое тестирование, что затруднительно при другом дизайне приложения.
Советую глянуть там четко все разложено.
https://dykyi-roman.github.io/projects/architecture-visualizer/?lang=ru#mvc/mvc
https://github.com/spring-backend-architecture/architecture-layered-sample/tree/main
Почему я перестал передавать Spring Pageable в контракты слоя приложения