кстати, я понял, почему Repo Pattern & UOW - отстой

а что разве нет?

а что разве нет?

пример, что да

пишешь интерфейс репозитория, и в его реализации пишешь любую сложную логику

пишешь интерфейс репозитория, и в его реализации пишешь любую сложную логику

э.. Repo + UOW

Repo не делает никаких соединений

но вообще да это мутная херня, поэтому в случае несокльких БД особенно разных форматов лучше event consistency

Repo не делает никаких соединений

почему это?

маппер инджектим в репу и погнали

Потому что открытие сессии это не есть задача репозитория

Потому что открытие сессии это не есть задача репозитория

или можно коннекшн заинджектить

или конекшн фактори

или можно коннекшн заинджектить

А теперЬ мы потолкуем

или конекшн фактори

это тоже есть

А теперЬ мы потолкуем

как?

ведь Named это антипаттерн

Меня разраб SimpleInjector послал с этой просьбой

Не понял ты о чем

Вот есть GiftRepo - это интерфейс

и лежит он в доменно слое, содержит только красивые названия методов

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

И?)

А есть низкоуровневая фигня из Infrastrucutre - GiftTarantoolRepo, GiftMysqlRepo - и т.д - туда прокидываем коненкшн или фабрику коннекшнов

он подерживает 2 и более базы данных?

Какое угодно количество, потому что вообще не привязан к понятию базы

Также можно создать условный GiftComplexDbRepo - и в нем уже работать с чем хочешь, обеспечивая транзацкционность на стороне приложения а не бд(что в распределенных системах вообещ невозможно) хотя вроед у моськи что то видел про транзакции в рамках одного хоста

И?)

Зачем нам UoW при 1 действии?

Зачем нам UoW при 1 действии?

https://github.com/doctrine/doctrine2/issues/5550

крч вот твой goal, да?

да даже не при 1- он тоже может быть не нужен, просто в ряде случаев до флуша не доходим в случае ошибки, и все отменяется

https://github.com/doctrine/doctrine2/issues/5550

лол там про моего начальника предыдущего)

щас прочитаю

земля круглая ебанаврот

Какое угодно количество, потому что вообще не привязан к понятию базы

как ты будешь строить граф зависимостей до сессии

https://github.com/doctrine/doctrine2/issues/5550

Получается типо того. Только это не обязательно TableGateway

https://github.com/doctrine/doctrine2/issues/5550

и что в итоге это плохо считается?

Зачем нам UoW при 1 действии?

Чтобы не думать про количество действий

да даже не при 1- он тоже может быть не нужен, просто в ряде случаев до флуша не доходим в случае ошибки, и все отменяется

Лол, а если дошло, то что делать?)

как ты будешь строить граф зависимостей до сессии

Граф зависимостей чего?

Лол, а если дошло, то что делать?)

все зафлушится и сохранится!

да даже не при 1- он тоже может быть не нужен, просто в ряде случаев до флуша не доходим в случае ошибки, и все отменяется

Короче, просто попробуй пожить без uow, может он тебе действительно не нужен

Короче, просто попробуй пожить без uow, может он тебе действительно не нужен

в текущем проекте в существенной части репозиториев его нет...а там где есть ка кобычная зависимость идёт

Граф зависимостей чего?

https://github.com/simpleinjector/SimpleInjector/issues/531

короче я так понял что EM это тимо отдекорированный репозиторий

Найди там ошибку в моем ДНК, когда я выбирал эти паттерны

Двое разрабов SI не в курсе

в текущем проекте в существенной части репозиториев его нет...а там где есть ка кобычная зависимость идёт

Как ты добаляешь сущность? А как получаешь?

Как ты добаляешь сущность? А как получаешь?

получаю методом find по id например

добавлюя через new а потом пизаю ее в метод save()

добавлюя через new а потом пизаю ее в метод save()

У репозитория метод save?

да

да

https://www.slideshare.net/Yaboomaster1/save-repository-from-save

да

Так себе, советую подумать над переименованием в add или типа того

https://www.slideshare.net/Yaboomaster1/save-repository-from-save

+ только найти хотел

Так себе, советую подумать над переименованием в add или типа того

щас скажу точно

да точно add мы назыаем

save часто как приватный метод

щас скажу точно

главное что бы там небыло flush

потому что если у тебя там flush для глобального UoW.... то это так себе идея. сомневаюсь что у тебя круто изолированный агрегат

Ребятки, а посоветуйте годный материал по доктрине. Концепции, практики и т.д. Кратко и по делу. Помимо мануала. Спасибо

Ребятки, а посоветуйте годный материал по доктрине. Концепции, практики и т.д. Кратко и по делу. Помимо мануала. Спасибо

https://ocramius.github.io/doctrine-best-practices/#/

потому что если у тебя там flush для глобального UoW.... то это так себе идея. сомневаюсь что у тебя круто изолированный агрегат

КОгда норм агрегат есть, то у нас обычно на событиях все. А в репозитории метод save в котормо вызывается EventIterator::forEachEvent - и в нем персистнс для каждого события описан, я вот не уверен что это правильно. Как вы делаете?

КОгда норм агрегат есть, то у нас обычно на событиях все. А в репозитории метод save в котормо вызывается EventIterator::forEachEvent - и в нем персистнс для каждого события описан, я вот не уверен что это правильно. Как вы делаете?

@desper1989 эт у тебя хотел спросить в тот раз но забыл

@fes0r danke

ERROR: S client not available

https://stackoverflow.com/a/48573496/444079

КОгда норм агрегат есть, то у нас обычно на событиях все. А в репозитории метод save в котормо вызывается EventIterator::forEachEvent - и в нем персистнс для каждого события описан, я вот не уверен что это правильно. Как вы делаете?

мы по postFlush мутим а там где надо персистить события все prooph делает. Но если тебя интересует как бы мы чисто на доктрине в рамках транзакции персистили бы ивенты - это по preFlush какому

достаем сущности из UoW, ищем корень агрегата и достаем из него ивенты

в чем отличие Table Data Gateway (Шлюз к данным таблицы) и Data Mapper () можно в крации пояснить?

ППКС

єто слишком кратко

как по мне они обое играют роль шлюза в работе с таблицой

достаем сущности из UoW, ищем корень агрегата и достаем из него ивенты

что такое коренЬ агрегата

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

что такое коренЬ агрегата

представь себе агрегат как дерево объектов. И у этого дерева должен быть корень.

и через этот корень ты должен взаимодействовать со всем остальным деревом. Точнее корень как бы скрывает что там есть кто-то еще.

в чем отличие Table Data Gateway (Шлюз к данным таблицы) и Data Mapper () можно в крации пояснить?

Data Mapper о том как мэпить данные. Table gateway о том как ходить в базу. Они друг другу даже не конкуренты

в чем отличие Table Data Gateway (Шлюз к данным таблицы) и Data Mapper () можно в крации пояснить?

table data gateway мапит таблицы в объекты и обратно (1 таблица 1 объект) и оно больше привязано к структуре data mapper мапит реляционную структуру в сущности и обратно (1 сушность может быть в нескольких таблицах)

table data gateway мапит таблицы в объекты и обратно (1 таблица 1 объект) и оно больше привязано к структуре data mapper мапит реляционную структуру в сущности и обратно (1 сушность может быть в нескольких таблицах)

я вот не уверен что table gateway обладает таким ограничением что строго в одну таблицу.

я вот не уверен что table gateway обладает таким ограничением что строго в одну таблицу.

ну да это "упрощение" которое я допустил

строго этого нет, тут ты прав

https://www.martinfowler.com/eaaCatalog/tableDataGateway.html

https://www.martinfowler.com/eaaCatalog/dataMapper.html

только хотел эту же ссылку дать

ну то есть data mapper именно мэпит, а TableGateway просто скрывает SQL

то есть в table gateway спокойно можно разместить incrementCounter а в data mapper надо что бы объект, на который мы мэпим, умел со счетчиками работать. А мэппер бы просто мэпил.

ну table gateway как бы говорит есть table и есть gateway (шлюз доступа туда)

есть некая сущность которая по структуре соответсвует строке (обычно)

это все очень упрощенно

в datamapper сущность не обязана соответствовать строке там чуть другое)

ну table gateway как бы говорит есть table и есть gateway (шлюз доступа туда)

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

да это я понимаю