но это если загоняться

я пока больше склоняюсь к "жирному агрегату"

Такой вопрос к всем тем кто использует ОРМ - считаете ли вы что обьект который маппиться на базу и должен быть доменный обьектом или в идеале нужно различать эти сущности ?

В домене у тебя независимые от ОРМ объекты. Ты можешь query'ить и крутить-вертеть свой домен без базы

Я тоже к такой мысли пришел какое-то время назад - видел в джава мире очень много проектов где именно ORM обьект были еще вдобавок доменные обьекты (в основном связка орм+домен + доменные сервисные обьекты в которых логика посложнее)

Привет. Не подскажите, в чем приемущества Repository перед DAO?
В том случае если хочешь писать какие-то оч сложне запросы, если не нужен UoW и IedntityMap и код не выстроен полностью по всем канонам DDD, то как по мне время на реализацию абстракции в виде Repository и сложность, которую она добавляет ставит под вопрос рациональность использования данного подхода на начальных этапах проекта. По сути, и DAO и Repo через интерфейсс реализуют какой-то DAL, но у DAO при этом больше гибкости.
Подойдет ли подход с построением приложения изначально через DAO, a при возникновении необходимости уже переводить каки-то части на репозитории?

У тебя код работает с объектами, достаёт и сохраняет их через репозиторий. А репозиторий как-то куда-то их сохраняет, и доктрина с бд - это лишь деталь реализации.

> в чем приемущества Repository перед DAO
Не то чтобы прям преимущества 🤔 Репозиторий - более простая/ограниченная абстракция (коллекция объектов), со всеми вытекающими.

> Подойдет ли подход с построением приложения изначально через DAO
Who knows. DAO - более низкоуровневая абстракция (от того и более гибкая).
"With great power comes great responsibility". Со всеми этими dao->insert/update и ожиданием in-place эффекта бывает сложно выстроить потом границы транзакций.

> если не нужен UoW и IedntityMap и код не выстроен полностью по всем канонам DDD
Это же не цель. Может и ActiveRecord зайдет в вашем случае

> время на реализацию абстракции в виде Repository и сложность, которую она добавляет

Если абстракция Repository добавляет сложности - что-то пошло не так. Тем более не ясно про "время на реализацию"

В общем говоря - пофиг как оно там называется. Абстрагировал доступ к данным - молодец (или нет, если апка в 500 строк, и никому лишняя когнитивная нагрузка в виде DAL абстракций нахуй не нужна)

пасиб)

Шта ?

Доктрина - Hibernate из мира пхп.

Зачастую внутри репозиториев можно увидеть EntityManager (деталь реализации)

зависит от реализаци ORM (AR, DataMapper), зависит от характера бизнес логики, зависит от того как ты модель данных проектируешь.

Скажем если у тебя схема базы оптимизирована под read операции то лучше конечно не делать 1:1 мэппинг объектов и табличек для операций записи. Если схема оптимизирована под запись а для чтения у тебя там вьюшки/материализованные вьюшки/проекции/не болит + data mapper - то почему бы не юзать напрямую.

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

Главное что стоит запомнить - универсальных решений нет. Даже внутри одного проекта могут спокойно сосуществовать несколько концептов - важно только определить в каких ситуациях что юзать. А так у тебя профиль юзера может быть через AR сделан (потому что тупой круд) и какой простенький документооборот уже более затейливо.

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

В этом контексте нет преимуществ.

Репозиторий нужен как способ абстрагировать персистенс когда у тебя за консистентность приложение (агрегаты) отвечают. Это не всегда и не везде нужно.

Репозиторий это "коллекция без итератора" очень упрощённо - такой интерфейс для key/value хранилища который позволяет тебе хранить агрегаты. Они в основном нужны на запись

Мэпа условная будет неплохим вариантом как себе репозиторий представить

Никто и не говорит что одно решение всем подойдёт :)

Ответ в целом предполагал "подумать", а не брать то, что "лучше"

тут могут дети впечатлительные читать а ты им "пофиг как называется"...

😄 Изначальная постановка вопроса "... Проект сделан не по канонам DDD ..." сразу настраивает на какое-то негативное суждение. Будто есть погоня за привнесением в проект фэнси-терминов, без понимания как мотивов, так и решаемых проблем