AC
Добрый день. Можете пожалуйста подсказать в чем отличие между DAO и Repository, и что каждый должен делать? В сети четкого ответа почему то не нашел
Как то давно читал на хабре, вроде это должно помочь https://habr.com/ru/post/263033/
Size: a a a
2021 January 19
N
Как то давно читал на хабре, вроде это должно помочь https://habr.com/ru/post/263033/
благодарю
MG
да я при чем не говорил отказыватся от консистенсности я предожил сделать ее eventual
Также преложил forigin ключи в базе на случай немедленной консистености но после этого меня вообще решили игнорировать.
Я то думал если человек не может через forigin ключ то у него система распределенная...
Но оказалось все несколько страшнее
Или вы противник eventual consistency?
Также преложил forigin ключи в базе на случай немедленной консистености но после этого меня вообще решили игнорировать.
Я то думал если человек не может через forigin ключ то у него система распределенная...
Но оказалось все несколько страшнее
Или вы противник eventual consistency?
Я сторонник не додумывать за кого-то его потребности. Для меня ситуация не выглядит как таковой, где нужно внедрять eventual consistency
N
Как то давно читал на хабре, вроде это должно помочь https://habr.com/ru/post/263033/
а если у меня небольшой проект / относительно простая архитектура, я могу реализовать код работы с БД в репозитории и сделать чтобы сервисы обращались к репозиторию для чтения и записи данных? имееттся ввиду вот прямо в репозитории писать sql запросы?
AC
а если у меня небольшой проект / относительно простая архитектура, я могу реализовать код работы с БД в репозитории и сделать чтобы сервисы обращались к репозиторию для чтения и записи данных? имееттся ввиду вот прямо в репозитории писать sql запросы?
Да, но вам нужно учесть что сервисы прямо не ходят в репозитории, сервисы используют контракты, а там уже через di биндите контракт к реализации
SF
а если у меня небольшой проект / относительно простая архитектура, я могу реализовать код работы с БД в репозитории и сделать чтобы сервисы обращались к репозиторию для чтения и записи данных? имееттся ввиду вот прямо в репозитории писать sql запросы?
Репозиторий как раз нужен для того, чтобы скрыть реализацию, а вы ее наружу выставляете.
SF
Да, но вам нужно учесть что сервисы прямо не ходят в репозитории, сервисы используют контракты, а там уже через di биндите контракт к реализации
А кто ходит?
N
Репозиторий как раз нужен для того, чтобы скрыть реализацию, а вы ее наружу выставляете.
я скрываю реализацию в самом репозитрии, сервисы же будут видеть абстракцию в виде репозитория? или неверно?
AC
А кто ходит?
Дополнил ответ
SF
я скрываю реализацию в самом репозитрии, сервисы же будут видеть абстракцию в виде репозитория? или неверно?
Да, сервисы видят абстракцию. Но эта абстракция не должна на вход принимать, например SQL запрос
N
Да, сервисы видят абстракцию. Но эта абстракция не должна на вход принимать, например SQL запрос
конечно нет)
SF
Дополнил ответ
👍
N
имею ввиду repository.findById(id) - а сам запрос уже в репоизтории внутри делается
SF
имею ввиду repository.findById(id) - а сам запрос уже в репоизтории внутри делается
Да, именно так
N
Да, но вам нужно учесть что сервисы прямо не ходят в репозитории, сервисы используют контракты, а там уже через di биндите контракт к реализации
контракт это я так понимаю еще один паттерн?)
AC
контракт это я так понимаю еще один паттерн?)
Контракт в программировании реализуется интерфейсом
SF
контракт это я так понимаю еще один паттерн?)
Интерфейс
MG
Вот я спрашиваю: где с точки зрения ddd она должна происходить?
У меня нигде нет супер DDD подхода, но валидацию существования входящих данных для бизнес-логики я оставляю вне домена. Валидацию внутреннего поведения (например компании есть но они должны быть с одной страны и т.д.) - это валидация бизнес-логики и должна быть внутри домена
SF
У меня нигде нет супер DDD подхода, но валидацию существования входящих данных для бизнес-логики я оставляю вне домена. Валидацию внутреннего поведения (например компании есть но они должны быть с одной страны и т.д.) - это валидация бизнес-логики и должна быть внутри домена
И вы такую логику (компания с одной страной) помещаете в доменный сервис?