Size: a a a

Software Design/Architecture/Zen

2021 July 12

SP

Sergey Protko in Software Design/Architecture/Zen
"сковывает" или "изолирует"? Просто мы никогда не хотим что бы чёт сковывало.

Не оч понятно короч формулировка
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Инкапсулирует.
> что за сковывание вообще, я думал это автокомплит не верно сработал, есть такой термин?
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Ну там тип орм примитивные, нельзя просто сказать "вон классы, вон конфиги, а теперь работай" (это не совсем правда, но на фоне c#/java это так)
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Всё-таки «изолирует» уместнее)
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Мб мб.
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
не то чтоб я сильно любил doctrine, но для большого числа случаев умеет это делать уже 15(?) лет как. Правда в первой версии там вроде active record был
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Ну doctrine да, но это все ещё не "вау", хотя я давно ее не смотрел. Но щас же модно Лару юзать, так что ручками ручками. Ахах
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Лучше ручками чем глобальные uow
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Почему нет?
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Что не так с uow per request
источник

SP

Sergey Protko in Software Design/Architecture/Zen
А
Чем плохи неявные границы транзакции?
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
🤷‍♂
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
могу предположить что это проблемы:
1)  в плане производительности, могут открываться лишние транзакции, хотя думаю нет проблем сделать это настраиваемым. Мне например более привычна ситуация когда сами транзакции открываются явно там где надо, ну или не явно, но без заранее определенного места вызова. Но даже при таком раскладе это некий выбор который общий для всего проекта, то как оно будет.
2) нельзя делать лишних телодвижений в левых местах, потому что кто-то может забыть их убрать, а кто-то другой зафиксировать позднее, но я всего один раз видел такую проблему, так что не думаю что это хороший аргумент
Мб у тебя есть какие-то более сильные аргументы, раз ты так против.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Надо уточнить "против чего" и "за что ты". Я про api вида "достал - оно добавилось в uow, а потом где-то коммит. И не забудь почистить если чёт не так пошло
источник

˸A

˸̧̨ ͅBlack Akula˸̧̨ ... in Software Design/Architecture/Zen
Это же был наводящий вопрос - который должен был помочь понять, чем плох глобальный юов
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Все те кейсы которые в руках неопытных разработчиков (а их большинство) приводят к неявным зависимостям
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Тебе может с разработчиками везло а я повидал всякого
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
ну я за то чтобы "достал - оно добавилось в uow, а потом где-то коммит", а чистить... зачем чистить, просто не делать лишнего, тогда не надо чистить
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
не то чтобы я был против чего-то, разве что против того чтобы в разных частях проекта делать это разными способами, тут я точно против) но тут как бы никто и не за
источник

˸A

˸̧̨ ͅBlack Akula˸̧̨ ... in Software Design/Architecture/Zen
Наверное, вы не работали с highly distributed systems? Или хотя бы с документ дб без встроенных в СУБД транзакций?
источник