Всем привет, продолжаются мои похождения по миру ООП. Вот есть паттерн

репозиторий. Это абстракция над персистансом.

Пример условной задачи: есть набор сущностей, у них соответсвующие поля и связи. Возмем для примера.. Что там берут для примера всегда?

Возьмем Event, у него есть Country. Связь m2o.

Иногда хочется создать Event с Country вместе, а иногда — сначала Country, а затем Event.

Кто как считает:
— Должен ли репозиторий работать только с одной сущностью и не знать ничего про другие? Если да, то как быть тогда со связами?
— Данные какого формата из внутреннего слоя должен принимать репозиторий? DTO/POXO или обьекты БЛ?
— Какого формата во внешний слой должен возвращать репозиторий? DTO/POXO или сначала он должен воссаздать обьекты из данных персистанса и только затем передать во внутренний слой?

И в целом расскажите что вы думаете по поводу всего этого, что почитать куда сходить.

Исходная задача: инкапсулировать работу с персистансом за абстракцией, что бы не смешивать ее с БЛ во внутреннем слое.

А причём сохранение здесь?

да, или .save()

"findProductsByCustomersThisYear - отдельный сервис" отдельный сервис где? domain service? "репозиторий это не гейтвей к табличкам в базе" т.е. мы можем сделать отдельно гейтвей и репозиторий у которых будет по сути один и тот же код работы с табликами в бд (просто в репозитории персисентс домейн сущностей, а в гейтвее более общие запросы)?

а где хочешь. Например интерфейс может быть определен во view (там где нам нужна зависимость) а реализация в инфраструктуре. Но при этом все это просто три файлика в папке (потому что слои не папки). > т.е. мы можем сделать отдельно гейтвей и репозиторий у которых будет по сути один и тот же код работы с табликами в бд (просто в репозитории персисентс домейн сущностей, а в гейтвее более общие запросы)? там не будет "один и тот же код" так как скорее всего структуры данных для UI и для бизнес логики будут различаться. Если они у тебя не различаются - значит либо чо-то в декомпозиции не так либо у тебя тупой круд и че ты там вообще выпендриваешься со своими слоями.

имею ввиду что это ок будет если формировать запросики к бд будет и репо, и гейтвей?

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

👍

Неа, в этом разница между регистром и стором

вставлю 5 копеек. есть 2 типа репозиторией collection like и storage like, первый может только дай и положи, а второй еще и сохрани

Вот второе не репозиторий) это сторадж или гейтвей

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

а в чем разница между "положи" и "сохрани"?

то и означает... положил на стол, а не в сейф 🙂

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

Зачем тебе класть то что там уже есть

ну да, идеологически верно

Сырые запросы и погнали). Имеется ввиду для выборок

Не понял при чём тут сваггер. Проблема в том, что с сырыми SQL-запросами будет резал-сет, который надо ещё обработать прежде чем из него получится красивая структура с вложенными объектами.

А ты про это, не понял сначала

достаешь вторую карту из рукава - спецификации 😈