A
Все ещё люди спрашивают, как удалить из таблицы без селекта, Карл!!1
Ну вот этот момент конечно бесит в еф, +100500
Size: a a a
2020 July 23
VS
А еф для своей области очень проста, а скл запросы не так просты как кажется, особенно, если идут изменения в бд. Изменил поле, провтыкал какой-нить скл и ошибка в рантайме. Хорошо, если тесты есть, а если нет? Они же не всегда есть.
вот кстати еще один топовый проект, который есть на джаве и нужно портировать на дотнет - TestContainers
AH
вот кстати еще один топовый проект, который есть на джаве и нужно портировать на дотнет - TestContainers
Ты аккуратнее. Очень просто уйти в джаву!
VS
))
AH
(писать на скале/котлине разумеется)
A
Да блять. Для какой области? Единственная область - гребля на галере
Для той, в которой реляционная бд используется как хранилище объектов, а не как бд со сложной логикой, в которой аналитические запросы по 100 таблицам катают и гигабайты данных льют со сложными управлениями жизнью транзакций.
Вот для таких бд, еф я конечно, никогда не возьму, ебли там будет просто колоссальное количество. Проще даппер взять.
Вот для таких бд, еф я конечно, никогда не возьму, ебли там будет просто колоссальное количество. Проще даппер взять.
VS
на старте проекта никогда не знаешь во что он выльется, а потом уже ef выпиливать будет очень сложно
VS
Для той, в которой реляционная бд используется как хранилище объектов, а не как бд со сложной логикой, в которой аналитические запросы по 100 таблицам катают и гигабайты данных льют со сложными управлениями жизнью транзакций.
Вот для таких бд, еф я конечно, никогда не возьму, ебли там будет просто колоссальное количество. Проще даппер взять.
Вот для таких бд, еф я конечно, никогда не возьму, ебли там будет просто колоссальное количество. Проще даппер взять.
Я тебе завидую. Прямо на старте знаешь, что будет
VS
Я руководствуюсь только одним правилом - код должно быть легко расширить, переписать или выкинуть
VS
а как же правило ставить меньше пробелов?
TK
(казалось бы, причём тут Украина)
VS
а как же правило ставить меньше пробелов?
Есть правило ставить больше. Я его не соблюдаю
Н
EF удобно использовать на стороне command в CQRS, когда нужно оперировать полными агрегатами. А на старте проекта, когда нужно быстро херак-херак и в прод, можно использовать и на стороне query, пока не будут очевидны проблемы производительности в конкретных запросах. После этого можно точечно и итеративно выпиливать ef из нужных запросов и заменять на всякие дапперы.
A
Я тебе завидую. Прямо на старте знаешь, что будет
Обычно в начале проекта понятно, в какую сторону он пойдет. Особенно после мвп.
VL
для меня основной причиной отказа от ЕФ был жор памяти и процессора при больших нагрузках. при запуске стресс тестов сотни запросов пожирали гигабайты памяти и нагружали камень так, что все остальное переставало шевелиться. по итогу запросы перенес в хранимые процедуры и написал самопальный десериализатор объектов, которые возвращались из хранимок. скорость обработки увеличилась в среднем в 20 раз и потребление памяти упало до уровня погрешности.
VS
Обычно в начале проекта понятно, в какую сторону он пойдет. Особенно после мвп.
Эххх
VS
для меня основной причиной отказа от ЕФ был жор памяти и процессора при больших нагрузках. при запуске стресс тестов сотни запросов пожирали гигабайты памяти и нагружали камень так, что все остальное переставало шевелиться. по итогу запросы перенес в хранимые процедуры и написал самопальный десериализатор объектов, которые возвращались из хранимок. скорость обработки увеличилась в среднем в 20 раз и потребление памяти упало до уровня погрешности.
А мог бы даппер взять
VL
в моем случае все равно лучшим решением был перенос логики в хранимые процедуры, а десериализатор написал в течении дня. простенький правда, чисто для своих нужд. но работает нормально при соблюдении некоторых условий и я его сейчас использую в разных проектах
VS
лучшим с какой точки зрения?