Идея Милана предполжительно в получении максимального перформанса. У Ника Чапсаса есть относительно свежее видео, где он сравнивает производительность даппера и ef, и у него получается, что обе технологии имеют паритет по записи, но читает даппер быстрее раза в четыре, чем ef. Если основываться на результатах бенчмаркинга Ника, то схема Милана должна дать приложению максимальную скорость работы. Видимо нюанс того, что разработчику на проекте придётся знать обе технологии, остался за кадром.
Может быть. Я тестил строго маппинг и получал одинаковые результаты. Может где-то что-то упустил. К сожалению, сейчас нет возможности воспроизвести результаты.
Так це ж і є головна фіча cqrs. Дуже здивувався висновку, що швидкість однакова, бо не 1 раз бачив імплементацію cqrs як раз через схему ef+dapper(мова про +- нові проекти з чистою архітектурою)
Дякую, EF не використовуємо. Достатньо Даппера. Для інсерт/апдейт користуємось зазвичай сторед процедурами, назви яких як атрибут додаємо до потрібного енума, щоб на рівні репозиторію необхідну СП не шукати, а через енум
абсолютно згодний з автором 👍 dapper - чудовий тул, який вирішує конкретну задачу... ef - вирішує цілий напрям, але і навязує нам свої правила)) використовую в залежності від проекту
Я був колись на проекті, де обрали даппер замість ентіті. Оскільки мені подобається писати квері, спочатку я кайфував, потім проект виріс і його потрібно було підтримувати. І тоді я хапнув горя) Тепер тільки ентіті. А даппер чи щось таке для місць, які потребують особливої уваги.
Ну, спорный момент касательно отсутствия трейдоффа сложности еф и сложности скл. Я, например, знаю все перечисленное про скл, но написать такую ров-кверю у меня займет часа 3-4, а на еф с флуент апи - 20 минут. Еф позволяет базово знать и понимать, что как устроено. Даппер и сырой скл в принципе требует очень четкого понимаю, что, где и как.
Хм... По моему опыту EF с Fluent Api в целом не умеет в сложные запросы: pivot, window function, etc. Ну а простые... Ну может кому-то и удобнее на EF: вкусовщина.
Дякую за випуск. Теж дивився Мілана з цієї теми. Але я от чого не можу збагнути. Окей, EF це монстр і він заскладний якщо спробувати його використовувати весь, але що заважає використовувати його так само просто як Dapper? Я бачу сценарій коли простий початок з Dapper або заміна ним складності EF зрештою приведуть до того що все стане ще складніше. Гадаю EF має відповідну складність до загальної можливої складності розробки, а Dapper це ситуативне рішення яке може на деякий час полегшати розробку, але потім буде ще гірше. Всі хто колись писав бізнес-логику в Stored Procedures знають у що воно може перетворитися за кілька років. На мою думку якщо на якомусь етапі EF став дуже складним то з проекту треба виділяти мікросервиси.
Всім кому EF генерує не такі запроси можна використовувати EF Core SQL Queries. Посилання в коментах чомусь видаляються, але як завжди все в доках від MS
"важко найматы шарящих ЕФ" - да камон, если .Net дев, даже джун, не интересовался лучшей ОРМ в мире (да), то зачем его вообще нанимать? В код ревьюверы одного шарящего и с полиси - атачить примеры СКЛ запроса для новых ЕФ методов сложнее "гет бай айди" (по факту пользы больше будет от того, что сам дев эту кверю и посмотрит лол). В остальном согласен. Из опыта, самое страшное, что было с ЕФ - захотели попробовать Inheritance - не взлетело, поверх всех проблем озвученых в видео добавилась еще сложность натянуть мир ООП на не совсем ООПешный СКЛ. В итоге сгенерированый запрос на 5 экранов и все дохло на детских обьемах данных.
Даппер навіть теоретично не підійде на тах проектах, де іде активна розробка зі зміною бд. А от коли бд вже не планується до змін, то можна і в скл запити погратися
Объяснения на украинском ему религия смотреть не позволяет. Да, в начале, немного сложно, потому что не знаешь некоторых слов, а потом привыкаешь. Очень годный контент! Продолжай в том же духе!
![ILLSLICK - WINTER IS COMING [Official Video]](http://i.ytimg.com/vi/dwTMeM1zIhQ/mqdefault.jpg)
![[LIVE] : ONE ลุมพินี : คู่มวยแห่งยุค (11 ตุลาคม 2567)](http://i.ytimg.com/vi/aTc7-tPYuJM/mqdefault.jpg)
Андрей, спасибо вам за канал.
крутезна тема дякую за розяснення.
Идея Милана предполжительно в получении максимального перформанса. У Ника Чапсаса есть относительно свежее видео, где он сравнивает производительность даппера и ef, и у него получается, что обе технологии имеют паритет по записи, но читает даппер быстрее раза в четыре, чем ef. Если основываться на результатах бенчмаркинга Ника, то схема Милана должна дать приложению максимальную скорость работы. Видимо нюанс того, что разработчику на проекте придётся знать обе технологии, остался за кадром.
Может быть.
Я тестил строго маппинг и получал одинаковые результаты.
Может где-то что-то упустил.
К сожалению, сейчас нет возможности воспроизвести результаты.
Так це ж і є головна фіча cqrs. Дуже здивувався висновку, що швидкість однакова, бо не 1 раз бачив імплементацію cqrs як раз через схему ef+dapper(мова про +- нові проекти з чистою архітектурою)
Дякую за такий контент!
Дякую, EF не використовуємо. Достатньо Даппера. Для інсерт/апдейт користуємось зазвичай сторед процедурами, назви яких як атрибут додаємо до потрібного енума, щоб на рівні репозиторію необхідну СП не шукати, а через енум
абсолютно згодний з автором 👍 dapper - чудовий тул, який вирішує конкретну задачу... ef - вирішує цілий напрям, але і навязує нам свої правила)) використовую в залежності від проекту
Дякую! Поки EF не використовував. Для моїх проєктів це занадто. Достатньо Dapper.
Я був колись на проекті, де обрали даппер замість ентіті. Оскільки мені подобається писати квері, спочатку я кайфував, потім проект виріс і його потрібно було підтримувати. І тоді я хапнув горя) Тепер тільки ентіті. А даппер чи щось таке для місць, які потребують особливої уваги.
Дякую за досвід)
Так, тоді даппер взагалі не навіщо?
Воно і на EF можна написати сирий запит і замапити його, якщо EF вже на проекті.
Андрій, ти дуже молодець. І дякую тобі за солов’їну.
Цікаво було послухати думку досвічаної людини. Можливо ця інформація мені якось допоможе в співбесідах в майбутньому
Ну, спорный момент касательно отсутствия трейдоффа сложности еф и сложности скл. Я, например, знаю все перечисленное про скл, но написать такую ров-кверю у меня займет часа 3-4, а на еф с флуент апи - 20 минут. Еф позволяет базово знать и понимать, что как устроено. Даппер и сырой скл в принципе требует очень четкого понимаю, что, где и как.
Хм...
По моему опыту EF с Fluent Api в целом не умеет в сложные запросы: pivot, window function, etc.
Ну а простые... Ну может кому-то и удобнее на EF: вкусовщина.
Дякую за випуск. Теж дивився Мілана з цієї теми. Але я от чого не можу збагнути. Окей, EF це монстр і він заскладний якщо спробувати його використовувати весь, але що заважає використовувати його так само просто як Dapper? Я бачу сценарій коли простий початок з Dapper або заміна ним складності EF зрештою приведуть до того що все стане ще складніше. Гадаю EF має відповідну складність до загальної можливої складності розробки, а Dapper це ситуативне рішення яке може на деякий час полегшати розробку, але потім буде ще гірше. Всі хто колись писав бізнес-логику в Stored Procedures знають у що воно може перетворитися за кілька років.
На мою думку якщо на якомусь етапі EF став дуже складним то з проекту треба виділяти мікросервиси.
Я в відео казав, що от не виходить юзати ЕФ не натикаючись на його складність...
@@DevJungles Та ну не. До той складності проекту зазвичай треба 3-5 років. А спочатку там взагалі немає нічого. Ну якщо не вважати міграцію складною.
Были затронуты чувства верующих)
Хех)
Всім кому EF генерує не такі запроси можна використовувати EF Core SQL Queries. Посилання в коментах чомусь видаляються, але як завжди все в доках від MS
"важко найматы шарящих ЕФ" - да камон, если .Net дев, даже джун, не интересовался лучшей ОРМ в мире (да), то зачем его вообще нанимать? В код ревьюверы одного шарящего и с полиси - атачить примеры СКЛ запроса для новых ЕФ методов сложнее "гет бай айди" (по факту пользы больше будет от того, что сам дев эту кверю и посмотрит лол). В остальном согласен. Из опыта, самое страшное, что было с ЕФ - захотели попробовать Inheritance - не взлетело, поверх всех проблем озвученых в видео добавилась еще сложность натянуть мир ООП на не совсем ООПешный СКЛ. В итоге сгенерированый запрос на 5 экранов и все дохло на детских обьемах данных.
Я мав на увазі прямо Шарящих.
Прямо от дійсно глибоко.
@@DevJungles прямо шарящих? а у нас тут таких нет, у нас все нормальные ребята
Даппер навіть теоретично не підійде на тах проектах, де іде активна розробка зі зміною бд. А от коли бд вже не планується до змін, то можна і в скл запити погратися
Да чому ж.
Якщо потужний db first і до нього окрема тіма, то це норм може спрацювати
Использовать еф кор в серверлесс архитектуре, мм, не очень вкусно)
Довге створення контексту і неможливість пулінгу ...
@@DevJunglesexactly
Це хлопiц дело молвит
Казав, що підпишусь, як перейдеш на українську.
Доне✅
Вже чи не пів року як))
@@DevJungles так, це вже на моїй стороні eventual consistency
Хех))
Истина на 7:40
Вроде и на украинском понятно, как ни странно)
Мне так нривились твои обьяснения и рассуждения. Сохраню твои старые видео, но увы, отпишусь.
good by
Ок
Объяснения на украинском ему религия смотреть не позволяет.
Да, в начале, немного сложно, потому что не знаешь некоторых слов, а потом привыкаешь. Очень годный контент! Продолжай в том же духе!
Давай лучше на олбанском!
Чем лучше?
Давай меньше пиздеть
@@DevJungles Намного понятнее
@@MrZuberbillerчисто для тебя канал вести?
😂