SP
еще я не люблю глобальный UoW - это удобно что бы по быстрому накидать и не заботиться о границах транзакций. Для маленьких простых проектов вообще топ. Но практика показывает что потом хер проссышь как и чего где меняется
Size: a a a
2021 June 04
SP
какие-то отдельные маленькие сервисы для выборок. которые плюются уже готовыми DTO
SP
в которых родной SQL
R
Но ведь тогда размазываются знания о том, как и где мы храним данные по проекту. Понятно, что переехать с базы на базу — это скорее миф. Но если меняется схема, нужно будет исправить тысячу мест
ST
Если система хранения на уровне файловой, то да. А если это СУБД с моделью данных по уровню, близкому к модели ПрОбл - нужно ей пользоваться
SP
1. схема меняется не так часто и не так координально
2. зависит от того как ты делаешь мэппинги и т.д. Где-то что-то менять в любом случае нужно будет. Куда интереснее когда изменения схемы влияют не на resultset а на саму логику фильтрации - тут твои ORM-ы тебе не помогут и количество изменений будет таким же. А для резалтсэтов все попроще и опять же их не миллион.
2. зависит от того как ты делаешь мэппинги и т.д. Где-то что-то менять в любом случае нужно будет. Куда интереснее когда изменения схемы влияют не на resultset а на саму логику фильтрации - тут твои ORM-ы тебе не помогут и количество изменений будет таким же. А для резалтсэтов все попроще и опять же их не миллион.
SP
ну то есть условно. Решили мы добавить новое поле - посчитай количество изменений. Нужно переименовать поле - в любом случае будем делать добавление/миграцию/удаление в несколько этапов что бы обратная совместимость.
SP
вот эта штука про "абстракция от СУБД" была полезна во времена когда все пытались продукты коробочными делать что бы мол "ой запускайте хоть на postgresql хоть на mysql" и т.д. Сейчас все движется в сторону cloud или более жестких требований для on-premise.
SP
можно конечно как Убер раз в 2-3 года переезжать с mysql на postgresql и обратно, но у них "спефицика". могут себе позволить
MT
А в чем, собственно, минус репозитория как ответственного сборщика (не важно read/write)? С делегированием именно ему (репозитарию) схемы мапинга (опять же, что из одного, что из нескольких хранилищ через storages). Без сомнения, кода может быть больше (но сделать 2 read/write, а-ля cqrs, как вариант)
А уже и сервисы и агрегаты все-же через репозиторий гонять...
А уже и сервисы и агрегаты все-же через репозиторий гонять...
MT
И изменений, при смены мапинга, будет меньше
МФ
не размазываются — не смешиваются изначально
домен — про бизнеси данные, необхожимые для бизнесухи
UI — отдельные знания, условн оговоря название на бирке и название бренда или описание товара никак не участвует в логике самого товара (неожиданно) условно
домен — про бизнеси данные, необхожимые для бизнесухи
UI — отдельные знания, условн оговоря название на бирке и название бренда или описание товара никак не участвует в логике самого товара (неожиданно) условно
SP
предположим что у тебя есть некий сводный отчет по продажам разбиты поквартально скажем. тебе там и заказы нужны, и покупатели, и поставщики, и категории товаров... в какой репозиторий ты это будешь складировать?
MT
Я разделю это контекстами
SP
ну то есть достать кучу данных из кучи хранилищь и "переизобретать sql на уровне приложения"?
SP
и давай не будем пока усложнять пример распределенными приложениями
SP
ну то есть, есть кейсы когда структуры данных на запись и на чтение если не 1:1 то "достаточно похожи". В этом случае все упирается только в ISP из SOLID
SP
опять же тебе никто не мешает складировать все это в одном классе и разделять интерфейсами
MT
Согласен
Просто везде нужен компромисс
Просто везде нужен компромисс