query классы содержащие в себе sql запросы к бд. А слой application сервисов просто форвардид вызовы на методы этих классов.
Выглядит избыточно, на мой взгляд. Usecase-specific запросы выносятся в отдельные классы без дальнейше цели их как-то переиспользоваться под предлогом отделения слоя базы данных от приложения. Пишется больше кода и больше проблем с его организацией.
Я бы писал такие запросы в application слое, а уже если вдруг появится необходимость переиспользования таких запросов, выносил бы куда-то.
Есть ли какие-то минусы в написании read запросов в application сервисах?
я ленивый и мне такой подход в целом нравится, но его очень сложно объяснять людям. Это тебе надо концепт слоев пересматривать (для людей то этот концепт простой и сквозной через весь проект). А потому чаще все ж прихожу к тому что "да избыточно зато одинаково и для тупых понятно". Но сам бы делал как ты описал и если команде ок - то ок)
враг такого — унификация местами и парвда удобнее процедурный стиль зафигачить
Я тут подумал. А ведь то, что я описал, это же тоже деление на слои. Если в апликейшн сервисах мы пишем голые SQL запросы и вызывает какой-нибудь execute, то execute как раз из слоя бд приходит и позволяет абстрагироваться от способа выполнения sql запроса. Если в апликейшн слое мы используем query builder, то как раз он и будет нашем слоем бд и будет абстрагировать от реляционной базы данных. Если мы выносим запросы в отдельные классы, то абстрагируемся от любого способа хранения данных и от библиотеки для обращения к бд. Но от этого будет плюс только если есть переиспользование этого слоя в разных юзкейсах – иначе все равно одинаковое кол-во файлов редачить при смене библиотеки или бд. Плюс больше кода писать, и его как-то организовать надо. Во всех трех случаях есть деление на слои, но разная степень абстракции
Обсуждают сегодня