Почему я не использую Entity Framework
HTML-код
- Опубликовано: 19 янв 2022
- Поддержать меня: boosty.to/mflenov
Это лично мои причины, почему я не использую Entity Framework. Это мой выбор, о котором я хотел рассказать, но это не значит, что вы должны следовать ему.
Обо мне: www.flenov.ru
Мой ИТ блог www.flenov.ru и www.flenov.info
Мой просто блог blo.moe
Tweeter: / flenov
Инстаграмм: / mflenov
Телеграмм: t.me/mflenov
В целом соглашусь. Единственные плюсы. которые вижу от EF, что все-таки код выглядит приятнее и легче в нем отследить ошибки, чем когда это прямые SQL-запросы, а так же легче вводить в курс дела начинающих программистов. С опытом, когда задумываешься о производительности и внутренностях - как это все утроено, то начинаешь видеть множество недостатков. Но так можно сказать и про сам C#, часто его не любят за большое количество абстракций, которых нет в том же C++, но за счет этих абстракций быстрее и проще можно поднять проект. Так что тут кому что. Сам я сейчас с удовольствием работаю с EF Core и вижу, что иногда есть просадки по производительности, но это скорее исключение, чем правило, поэтому надежность перевешивает желание оптимизировать. Спасибо за видео! P.S. Моки иногда пишу - бесит :).
Вы озвучили основную причину проблемы: "так легче учить начинающих программистов". Минус один язык программирования и никакого погружения в блокировки, уровни изоляции транзакций и все что связано с БД. Но Вы не поверите, я столкнулся с одним открытием. Эти самые начинающие программисты, даже имея уже приличный опыт, мыслят так, будто данные хранятся где-то внутри классов в каком то черном ящике. И из экземпляра этого самого класса данные и достаются. Такое виденье работает при создании корпоративных приложений с заведомо известной нагрузкой. А вот когда начинается разработка широковещательных приложений, с заранее неизвестными пиковыми нагрузками и дело упирается в хайлоад, то тушите свет.
Ооооочень интересное видео! Лайк
Мне вообще кажется, что лучше использовать ef только на запись каких-то сложных агрегатов, т.е. когда у нас корневая сущность может содержать вложенные списки (типо order и orderitems). Но при этом логику сохранения всё равно лучше выполнять в каком-то repository/unit of work/service, т.к. иногда надо заперсистить не только этот агрегат, но и что-то инфраструктурное. Тогда и тесты всё ещё просто писать, т.к. мы можем засетапить этот repository/unit of work/service) как нам надо.
Т.е. мы облегчаем себе жизнь при написании OLTP запросов (не пишем однотипные insert, update, delete).
Для чтения можем прочитать по id из базы этот заказ. Или применить какие-то простенькие фильтры для поиска, но только объектов этого типа. Опять же, для пагинации удобно заюзать skip и take.
Если же нужно построить какой-то сложный аналитический запрос с join-ами всего и вся (и ещё вопрос стоит ли использовать для этого реляционную базу данных), то проще просто написать старый добрый select руками.
Тогда в типичном сервисе для 80% запросов будет достаточно ef на инфраструктурном уровне хранения, а для всего остального можно и sql написать 🙂
Классное видео, пересматриваю уже второй раз) Было бы интересно еще про моки и тестирование в целом послушать ...
Как я тестирую я рассказывал на бусти. У меня вообще весь обучающий контент ушёл на бусти и здесь теперь девлог.
На самом деле - истина где то по середине. Проблемы в неправильном использовании инструмента (EF). Для некоторых случаев лучше EF использовать, например, редактирование справочников. Здесь упрощение и ускорение разработки. В EF удобно, то что изменение свойств автоматом мэппятся на апдейты, простая сортировка и фильтрация.
В сложных случаях типа использование EAV (Entity Attribute Value) пэттерна для хранения данных (когда данные хранятся в одной колонке как ключ - значение) - EF наоборот мешает, там нужны процедуры и функции БД.
Всегда мешает Code First и миграции средствами EF.
В EF сильные стороны - это динамическое создание фильтров, сортировки, мэппинг изменений на данные в БД.
Но с сортировкой тоже появляются проблемы, когда поле вычисляемое типа ФИО и его нет в БД- но если создать View и там определить вычисляемые поля, то проблема решается. Для этого нужен DbFirst.
Михаил, если я правильно понял про Моки, то смущает написание их вручную, верно? Я использовал библиотеку Moq и Nsubstitute, которые позволяют замокать любой интерфейс. Не использовал разве что-то подобного в юнит-тестах?
Даже с библиотекой никто особо не хочет писать их. Я использовал как-то Moq, это далеко не так и весело. Мне не понравилось.
"ПЕРЕДАСТ" - чоткое словечко) пожалуй сохраню в словарь)
Dapper очень нравится, но не понятно как быть, когда нужен граф объектов, например Автомобиль, Двигатель и Колеса, то тогда все равно приходится делать некий репозиторий, в котором Dapper вытащит из всех таблиц нужные данные и там соберет мне автомобиль. EF позволяет более удобнее вытянуть этот граф объектов из БД.
Ну да, тут тебе руками придется писать больше, потому что Dapper это всего лишь маппер без дополнительных прибамбасов.
Нормальное видео. Комменты однобоки, поэтому допишу. Исключены ошибки синтаксиса, это в первую очередь. Ты реально видишь где используется поле, можно удалить не используемые. Если запросы хранятся в стринге, попробуй поищи. Из коробки есть мигратор. То есть в любом случае надо подключать левую библиотеку для миграции изменений, даже если EF не используется. Ну и с тестами, есть in memory db, в связке с ef это просто сказка, а не тестирование. Про остальное - всё так, для сложных запросов не очень подходит, а если нужна оптимизация, то и вовсе надо переносить код в стрингу с обычным sql.
Да, используемые поля это тоже плюс ef, это тоже, снижает вероятность ошибок, опечаток
Я только делаю первые шаги в c#, но EF core скорее хорош в небольших проектах, когда нужно объем данных большой, сильно тормозит при запросах.
У нас на новом проекте начали использовать entity framework. Сделали разделение доменных моделей и persistence слоя, чтобы бизнес можно было как раз юнит тестами покрыть. Правда у нас еще и между доменом и персистенс сделали зачем-то дополнительный слой, который ничего не делает. Лид сказал - на всякий случай =/ Но интегрировать бизнес объекты и систему управления персистенсом по-моему еще более сомнительно) В целом по итогу особо ничего хорошего в entity framework не увидел. Даппер - наше все ;)
То, что разделили - это хорошо. А используете LINQ или SQL? EF же вроде позволяет использовать SQL
@@Dev-lessons мы, когда этот сервис начинали делать с EF весь смысл был в том, чтобы не писать SQL. Первоначально проект обещал быть довольно простым в плане общения с БД. Его особенность в том, что нужно сохранять/вытаскивать очень много довольно больших сущностей и их количество будет увеличиваться. Поэтому и приняли решение использовать EF, чтобы не описывать все это в SQL. Так то это плюс. Но в бэклоге уже начинаются задачи, для которых нужно углубиться в детали EF и почесать затылок) Получается та двойная работа, когда в SQL это сделать было бы проще, о которой вы упоминали.
Тут даже нечего добавить. Подписываюсь под каждым словом. Автору респект..
Хм, в видео речь только про получение данных, но я думал что вся прелеть EF что он в себе дополнительно включает UoW и ты трекаешь сущности а потом в одном запросе все изменения едут в базу. Как вы, Михаил, вносите изменения в базу? Открываете транзакцию и update пуляете ? Я практически во всех проектах с которыми работал использова EF
Ну отслеживать изменения моделей не такая сложная задача. Да, я использую UPDATE, но открываю транзакцию только тогда, когда нужно. А ты думаешь как EF сохраняет в базе данные? Он тоже использует UPDATE. То, что ты его не пишешь сам, не значит, что его нет, а написать абстракцию для UPDATE можно за пять минут, если не любишь его. Есть библиотеки, которые уже предоставляют тебе готовые средства для записи в базу, но при этом используют чистый SQL, а не LINQ.
даппер ван лав. работал на проекте с кучей данных (нефтянка), проект был на EF. В итоге в один момент понадобилась производительность и пришлось реализовать отдельный сервис, который напрямую ходил в базу данных обычными sql-запросами. С тех пор, уже 2 с лишним года не использую EF вообще. Так уж везло, что либо уже был даппер, либо проект был только у своего начала и мы коллективно выбрали даппер.
Обращение к БД через ef нужно выделить в отдельный слой уровня данных. Туда должны войти всё iqeriable запросы. На выходе должны быть ienumerable операции. Тогда не будет проблем с mock ами. А вообще ef менее эффективен чем, все-таки руками можно намного лучше оптимизировать. Но для простых обращений типа взять заказы за вчера он вполне норм.
Можно, но я видел всего два проекта с EF и в одном видел, как iqeriable тянулся аж до уровня контроллеров.
Ох... Какая периодическая боль у меня от EF.
EF Core навязывает первичные ключи, а для некоторых таблиц это не нужно (редко, но бывает).
В рамках одного контекста нельзя сделать несколько асинхронных запросов не дожидаясь ответа, можно обломаться.
Он постоянно захватывает объекты и не даёт освободить память сборщиком мусора. Нужно ручками указывать, что вот этот объект больше не нужен.
К слову о моках.
Решил я на днях начать внедрять DTO в проект. Архитектор не заложил их при старте проекта, ни кто не запарился раньше. Запарился я. Хотел подсунуть DTO для одной сущности только для нового функционала. Начал писать DTO и поле за полем на описание DTO потребовалось описать половину таблиц БД, что не входило в мои планы.
Моки таких чудовищ тоже не самая приятная штука, уж лучше как-то начать заполнять db in memory
Из плюсов EF: просто использовать в простых и средних по сложности случаях.
Как вы будете рефакторить запрсы к бд? Например, когда удалилась или переименовалась колонка? Сидеть и искать все такие места? Иногда хочется увидеть где используется поле. Опять искать?
Не переименовывай просто. Никогда не переименовываем, потому что если сайт под нагрузкой без наунтайма такое сделать не так просто.
@@Dev-lessons и не удалять?
@@evseevav Это уже более безопасно, но тоже редко, кто удаляет. Удаляй колонки без проблем, я надеюсь у тебя тесты есть, чтобы не проверить код. Если ты удалишь с EF тоже код придётся чистить вручную. Просто компилятор укажет быстрее на места, где подчистить, но если есть тесты и при нормальной архитектуре, это один файл в случае с SQL, а в случае с EF это может быть большое количество файлов. SQL не плодиться по BL файлам, он лежит в DAL, а в случае с EF, репозитории часто разброшены по BL.
Я проходил курсы по ms sql server, если человек знает как читать план запроса, то ef только мешается
Михаил подскажите, а как с отправкой запросов пакетом ? EF отлично с этим справляется как в даппере или ado.net сделать не представляю, пример insert 100 000 строк, ef отправляет пакетом, даппер по одному из-за чего нереально долго
Ну это как реализуешь. Я не знаю, как Entity Framework реализовывает это под капотом, это еще надо проверить, он же не делает ничего нереального, а вревращает все в SQL, и его уже отправляет. В Dapper - создай табличную переменную и из нее запихни данные в БД
SQL запрос позволяет включать в себя ряд команд, разделенных точкой с запятой. по меньшей мере t-sql. Пишешь кучу инсертов в запрос через ; и отправляешь на сервер.
Моя любимая тема, не люблю orm, т.к. по работе очень часто приходится разбирать то, что написали другие и очень часто никто связно не может обьяснить как и зачем это сделали. Когда используют чистым sql хоть есть шанс быстро найти и носом натыкать.
То же самое можно сказать и про SQL, особенно про любителей писать динамические SQL и особенно в процедурах. Не надо EF использовать везде и вся, есть простые запросы, строчка кода и всё работает вместо нескольких на SQL, есть что то сложное, напишите на SQL. Вы же не пытаетесь оптимизировать код переводя его на машинный, так и к чему тут такое...
Современный EF хорошо строит тривиальные запросы, а зачастую они и нужны, типа дай мне со вчера до сегодня. Можно комбинировать EF + Dapper. У ef более-менее неплохо сделаны миграции, а как в чистом Sql, если, для постргрес например. И напоследок у нас старое легаси на специфичной ORM и EF на этом фоне сказка просто.
Ну если старая ORM, то конечно же и EF будет крутым
Пользуемся linq2db и не знаем проблем :). не такой сложнонавороченный как entity, не такой пустой как даппер, золотая середина. И sql генерит адекватный
Ни разу еще не пользовался им
Полностью согласен с автором. Только SQL. Хотя многих подкупает Code First, но рано или поздно они все таки приходят к SQL(за всех не говорю).
я начинающий программист, но почему-то меня ef больше проблем доставляет, чем помогает, с прямыми запросами к бд намного проще работать
0:28 Все по фрейду! ))
entyty - прекрасный инструмент. Из опыта создания энтерпрайз сайтов. Он прекрасно работает для большинства функционала, и его запросы НЕ нужно использовать только для всяких результирующих таблиц(которых часто единицы в проекте ну 1,2, макс 3, что относительно всего проекта - жалкие проценты) с кучей фильтров и с кучей джойнов.. Для этого можно написать и прямую sql процедуру.(хотя, соглашусь, чаще всего сначала пишется на linq, а потом создается баг , что что-то тут перфоманс страдает на больших данных)... Каждый инструмент нужно правильно использовать ...неприсособленостсь фреймворка к малому проценту задач не повод от него отказываться.
Возможно оффтопик, но всё же - по поводу прослоек между базами данных и программистами я считаю что в ряде случаев прослойки нужны (фреймворки или внутренние api между командами программистов и т.д. - другой вопрос).
У меня на работе сложилась такая ситуация - программисты CRM системы умеют писать SQL-запросы, но они далеко не всегда пишут их оптимально. Из-за этого я написал свою собственную API к базе из которой им (CRM-щикам) нужны данные для отчетов, но эти данные создавает сервис за который я отвечаю в плане эксплуатации (open-source штуковина, которая решает свои бизнес-задачи). Собственно задачей API стало получение параметров для SQL-запросов (которые я какое-то время выверял на предмет оптимальности и скорости выполнения) от программистов и выдача им результатов в шаблонизированном JSON-виде.
Фреймворки и ORM необходимы, потому что они упрощают жизнь. А такие вещи как LINQ - это прослойка, которая на мой вкус добавляет больше проблем, чем преимуществ. Но это на мой вкус. Как я сказал в видео, если кому-то нравится LINQ, то они найдут для себя преимущества.
Чистый sql бесит тем, что не знаешь, забыл ли ты пробел, запятую или скобку пока не запустишь код. Даже с учетом что запускал запрос в БД, при переносе в код, можно ошибиться. А linq проверяется при написании.
так протестируй запрос в sql клиенте
Да, это недостаток SQL, это текст и проверки на ошибок автоматом нет, нужно тестировать.
@@Dev-lessons Особенно когда пишешь домашний проект, на рабочей базе тестируешь и где-то посередине insert не сработал. Производительность кодера точно повышается с linq.
@@nikolayn4022 Да, у него есть из коробки готовые вещи, но он же не единственный такой. Есть и другие ORM, которые упрощают ту же вставку
@@Dev-lessons Да, кстати, если бы EF+LINQ был бы идеальным решением, других бы ORM не было.
В большинстве своем автор прав.
Но думаю что гибридные системы лучший выбор.
Если работаешь с милиардами записей, то лучше работать с базой напрямую. Eframework вообще не удобен. Не читабельные запросы и головняк как их оптимизировать. Используйте процедуры с сохраненнвми планами запросов.
мне кажется EF хорош тем что все управление данными происходит на стороне кода (создание/обновление таблиц и записей), но получается меньше гибкости, все таки хранимые процедуры удобнее чем просто запросы
Мне SQL удобнее, но это дело вкуса. Конечно же абстрагироваться от SQL круто, но потеря гибкости для меня страшнее.
@@Dev-lessons Посмотрел ролик ruclips.net/video/XTHFG5C1a4M/видео.html, понял, что хранимые процедуры тоже не удобны. Спасибо, теперь понял на какие грабли могу наступить.
@@azizkudaikulov993 начинай иметь собственное мнение, а не понимать всё что ты посмотрел 🤣
Непонятен такой момент, ты говоришь если использовать Dapper, то можно получить модель с данными и отдать её BusinessLayer, т.е. у тебя модель объявлена не в Business Layer, а в Data Layer и содержит только данные без методов, а вся обработка этих данных находится в Business Layer?
В DataLayer находятся методы, которые возвращают просто массивы данных IEnumerable и передает их в BL. Никаких репозиториев и IQuerable в BL не должно быть
@@Dev-lessons А кто должен обратиться к слою данных, запросить их из слоя данных и передать в бизнес слой? Какой-то класс типа *Service?
@@Dev-lessons Михаил, сделай видео архитектуры приложений. Расскажи как ты видишь всё это деление на слои и тому подобное.
@@user-ii9xe4pu6x Нужно подумать на эту тему
@@Dev-lessons подумай пожалуйста над этим. Я думаю эта тема многим интересна. Мне бы тоже хотелось научится строить систему без всяких репозиториев, единиц работы и тому подобное.
Есть поверие, что бекенд программисты с большим опытом уходят на пенсию, становясь DBA))) Там чистый SQL, с которым приятно работать)) А все остальное - для зумеров
Программисты не хотят использовать моки.. это мощно ) а как же вы тесты без моков пишете? Или и тесты они писать не хотят? )
Они предпочитают интеграционные, когда используется база данных, потому что это проще, но тесты же выполняются медленнее. Я тоже непротив интеграционных, но и юнит тесты тоже нужны. А чтобы писать юнит тесты без модов, у бизнес уровня не должно быть зависимости от базы данных, репозиторием, IQueryable, на вход должны подаваться только IEnumarable, которые ты можешь подать классу без моков.
Ненавижу EF, только dapper
Про сложные запросы в EF и то что получается в профайлере - I Feel your pain. По части отладки - когда что-то посложнее - бесит время ожидания пока все скомпилируется. Были ситуации когда получался крэш в рантайме когда в where было условие с листом в котором много элементов (LINQ точно было). А так EF для простой логики очень удобно. Были у нас и самописные фреймворки с утилитами для генерации кода - жилось ничуть не хуже. Головная боль начинается когда руководство спускает директивы а-ля "доступ к бд только через EntityFramework и никаких сторед процедур и SQL"
зачем использовать передаста?))
Иногда нужно передать и передаст - самое лучшее решение
Bbbbm
SQL - слишком ручная тема для такой отрасли, как программирование, основное назначение которой - автоматизация всего и вся. В конце 90-х с SQL из терминала работали всякие трейдеры и торговые менеджеры, которые буквально откапывали данные из некой свалки под названием БД. И сейчас ничего не поменялось: SQL - это лопата землекопа, не слышавшего про экскаватор.
Разница между тем, чтобы написать SELECT на SQL и SELECT на LINQ минимальна. Ты же все равно пишешь код выборки, вопрос только в том, на какой языке ты это пишешь
Есть противоположное мнение. Через EF с данными работаешь зубочисткой, тогда как напрямую можно экскаватором. Это все с учетом производительности.
@@terabucks Попробуйте мыслить чуть более глобально. Что, если придётся работать не сотнями таблиц, а с тысячами и миллионами с высоким уровнем вложенности? SQL для этого не разрабатывался. Таких кейсов не существовало. SQL не масштабируется. Запрос на 10 экранов пробовали читать и понимать? Ладно, написать можно, но как это поддерживать?
Первый!!!
Мне непонятно, как это программисты отказываются что-то писать (mock-объекты). Программист - наёмный работник, у которого есть трудовые обязанности, за выполнение которых он получает зарплату. Если не хочешь что-то делать в коллективе, что тогда ты забыл здесь? Ищи другое место работы, другой коллектив, где всё будет устраивать. Какие-то нелепые капризы, тем более, что тесты в первую очередь полезны самим разработчикам, т.к. лучше потратить время на тест, чем потом тратить гораздо больше времени на отладку, поиск и исправление багов. Для меня такая ситуация просто абсурдная.
Вот такая печаль в США и Канаде.
Первый проект на ЕФе, ничего неще не освоил, а уже критикует... "Зачем нужно учить дополнительную надстроку" - целостность и гибкость кода, возможность легкой смены типа БД. И что за бред о моках - сами обо... с затягивание кверей в бизнесс, сами и плачут. Досмотрел до конца, понял причину нелюбви - гпроекты.
Кто сказал, что первый?