Работа с инфраструктурой сущности C

Последнее обновление: 15.08.2023

Время на прочтение

Entity Framework Core является рекомендованным и самым популярным средством взаимодействия с реляционными базами данных на платформе ASP NET Core. Это мощный инструмент который подходит для большинства сценариев, но, как и любой другой инструмент имеет свои ограничения. Долгое время бытовало мнение (и не безосновательно) что Entity Framework не подходит для высоконагруженных систем и в таких сценариях лучше использовать Dapper. Но время идет и Entity Framework развивается, в том числе в плане оптимизации. Помимо улучшения производительности самой платформы . NET, Entity Framework Core для NET 6 имеет ряд настроек и возможностей, призванных значительно улучшить производительность. В этой статье мы рассмотрим Entity Framework Core с точки зрения производительности и сравним его с Dapper используя актуальные версии на момент июля 2022 года. Посмотрим насколько рекомендация «перепишите все на Dapper» актуальна 🙂

Эта статья будет полезна разработчикам, которые используют Entity Framework Core в ежедневной работе, а также разработчикам высоконагруженных систем для актуализации знаний о возможностях последних версий Entity Framework Core.

Что такое Entity Framework

Данное руководство устарело. Актуальное руководство: Руководство по Entity Framework Core

Последнее обновление: 31.10.2015

представляет специальную объектно-ориентированную технологию на базе фреймворка . NET для работы с данными. Если традиционные
средства ADO. NET позволяют создавать подключения, команды и прочие объекты для взаимодействия с базами данных, то Entity Framework представляет
собой более высокий уровень абстракции, который позволяет абстрагироваться от самой базы данных и работать с данными независимо от типа хранилища.
Если на физическом уровне мы оперируем таблицами, индексами, первичными и внешними ключами, но на концептуальном уровне, который нам предлагает
Entity Framework, мы уже работает с объектами.

Первая версия Entity Framework — 1.0 вышла еще в 2008 году и представляла очень ограниченную функциональность, базовую поддержку ORM (object-relational
mapping — отображения данных на реальные объекты) и один единственный подход к взаимодействию с бд — Database First. С выходом версии 4.0 в 2010 году
многое изменилось — с этого времени Entity Framework стал рекомендуемой технологией для доступа к данным, а в сам фреймворк были введены новые
возможности взаимодействия с бд — подходы Model First и Code First.

Дополнительные улучшения функционала последовали с выходом версии 5.0 в 2012 году. И наконец, в 2013 году был выпущен Entity Framework 6.0,
обладающий возможностью асинхронного доступа к данным.

Центральной концепцией Entity Framework является понятие или entity. Сущность представляет набор данных, ассоциированных
с определенным объектом. Поэтому данная технология предполагает работу не с таблицами, а с объектами и их наборами.

Любая сущность, как и любой объект из реального мира, обладает рядом свойств. Например, если сущность описывает человека, то мы можем выделить такие свойства,
как имя, фамилия, рост, возраст, вес. Свойства необязательно представляют простые данные типа int, но и могут представлять более комплексные структуры
данных. И у каждой сущности может быть одно или несколько свойств, которые будут отличать эту сущность от других
и будут уникально определять эту сущность. Подобные свойства называют .

При этом сущности могут быть связаны ассоциативной связью один-ко-многим, один-ко-одному и многие-ко-многим, подобно тому, как в реальной базе данных
происходит связь через внешние ключи.

Отличительной чертой Entity Framework является использование запросов LINQ для выборки данных из БД. С помощью LINQ мы можем не только извлекать
определенные строки, хранящие объекты, из бд, но и получать объекты, связанные различными ассоциативными связями.

Другим ключевым понятием является Entity Data Model. Эта модель сопоставляет классы сущностей с реальными таблицами в БД.

Entity Data Model состоит из трех уровней: концептуального, уровень хранилища и уровень сопоставления (маппинга).

На концептуальном уровне происходит определение классов сущностей, используемых в приложении.

Уровень хранилища определяет таблицы, столбцы, отношения между таблицами и типы данных, с которыми сопоставляется используемая база данных.

Уровень сопоставления (маппинга) служит посредником между предыдущими двумя, определяя сопоставление между свойствами класса сущности и столбцами таблиц.

Таким образом, мы можем через классы, определенные в приложении, взаимодействовать с таблицами из базы данных.

Способы взаимодействия с БД

Entity Framework предполагает три возможных способа взаимодействия с базой данных:

Привет, друзья. В этот чудесный майский день мы продолжаем трудиться и сегодня хотим рассказать о том, что в мае OTUS запускает полюбившийся всем курс «Разработчик С#», а также отдельный курс по С# ASP. N ET Core. Традиционно, в преддверии старта курсов начинаем публиковать полезный материал. Поехали.

Вступление

В большинстве современных ASP NET Core приложений используется Entity Framework Core. Entity Framework Core – это технология для доступа к базам данных от Microsoft. Оно позволяет взаимодействовать с СУБД с помощью сущностей (entity), то есть классов и объектов NET, а не таблиц базы данных. Это самый известный и функциональный ORM – инструмент в C#. O RM — это object-relational mapping — отображение данных на реальные объекты.

Например, если разработчик напрямую работает с базами данных, программист должен думать о подключении, подготовке SQL и параметров SQL, как отправлять запросы и о транзакциях. А с помощью Entity Framework Core все это делается автоматически — разработчик работает непосредственно с классами NET.

Подходы ORM

У ORM есть несколько подходов.

Первый – Code First. Он подразумевает, что сначала пишется код на C#, а потом по этому коду создается база данных. Для этого подхода очень важно определить классы модели или entity, которая будет храниться в базе данных, описать ее в классах C# в виде модели, и написать класс контекста, который и будет работать с используемой базой данных. Подход Code First используется чаще всего программистами C#.

Второй подход — Database-First- подходит для тех, кто хорошо знает SQL, но в этом случае необязательно хорошо знать C#. Первым делом создается база данных, затем генерируется EDMX-модель базы данных. В этом XML в файле .edmx содержится информация о структуре базы, модель данных и маппинг их друг на друга. В Visual Studio есть графический дизайнер, с помощью которого можно работать с .edmx

Model-First – это третий подход ORM. Его часто используют архитекторы, так как при этом подходе можно не знать ни SQL, ни синтаксис C#. В этом случае сначала создается графическая модель EDMX, в это время в фоновом режиме создаются классы C# модели, а затем генерируется база данных на основе диаграммы EDMX.

Модели Entity Framework Core

Хотя существуют такие механизмы, такие как Fluent API и аннотации данных, возможно переопределить эти условности или дополнительные правила конфигурации.

Миграции

В процессе разработки вполне вероятна ситуация, что класс модели Entity Framework изменился, и приходится удалять и базу данных, чтобы сохранялось соответствие модели. Но при удалении базы данных удаляются и все данные из нее.

Чтобы сохранить данные при изменении модели, в Entity Framework Core существует функция миграции. Она позволяет последовательно применять изменения схемы к базе данных, чтобы синхронизировать ее с моделью данных.

В миграции существуют операции, которые позволяют удалять, добавлять столбцы и таблицы, внешние ключи, изменять настройки столбцов, добавлять, удалять и изменять данные, и так далее. При создании миграции автоматически создается класс, где выполняются операции, которые необходимы для применения миграции Up() и ее возврата в метод Down().

LINQ

С Entity Framework в NET неразрывно связан и LINQ. L INQ — это Language Integrated Query или Внутриязыковой запрос — это такая технология, которая представляет собой набор функций в NET, которые позволяют писать структурированные запросы к базе данных.

Для работы с Entity Framework Core использует технологию LINQ to Entities. L INQ использует похожие на SQL выражения языка C# для получения данных из базы данных. Любая реляционная база данных работает через запросы на языке SQL, и Entity Framework Core выражения LINQ to Entities транслирует в запросы SQL, которые понятны для используемой базы данных.

Заключение

Таким образом мы кратко пробежались по возможностям Entity Framework Core. Как вы увидели, он действительно очень мощный, причем настолько, что программисту, который с ним работает даже не обязательно знать SQL. И Entity Framework Core по праву принадлежит первое место среди ORM в мире NET.

Последнее обновление: 24.10.2018

Чтобы непосредственно начать работать с Entity Framework, создадим первое приложение. Для этого нам нужна будет, во-первых, среда разработки.
В качестве среды разработки выберем Visual Studio 2017.

Это обычный класс, который содержит некоторое количество автосвойств. Каждое свойство будет сопоставляться с отдельным столбцом в таблице из бд.

Затем в появившемся окне управления NuGet-пакетами в окне поиска введем слово «Entity» и выберем пакет собственно Entity Framework и установим его:

Основу функциональности Entity Framework составляют классы, находящиеся в пространстве имен System. Data. Entity. Среди всего набора классов этого
пространства имен следует выделить следующие:

В конструкторе этого класса вызывается конструктор базового класса, в который передается строка «DbConnection» — это имя будущей строки подключения к базе данных. В принципе мы можем не использовать конструктор, тогда в этом случае строка подключения носила бы имя самого класса контекста данных.

И теперь нам надо установить подключение к базе данных. Для установки подключения обычно используется файл конфигурации приложения. В проектах для десктопных
приложений файл конфигурации называется (как в нашем случае), в проектах веб-приложений — . В нашем случае,
поскольку у нас консольное приложение, это файл . После добавления Entity Framework
он выглядит примерно следующим образом:

Теперь перейдем к файлу и изменим его содержание следующим образом:

В результате после запуска программа выведет на консоль:

Объекты успешно сохранены
Список объектов:
1. Tom — 33
2. Sam — 26

Таким образом, Entity Framework обеспечивает простое и удобное управление объектами из базы данных. При том в данном случае нам не надо даже создавать базу данных
и определять в ней таблицы. Entity Framework все сделает за нас на основе определения класса контекста данных и классов моделей. И если база данных уже имеется,
то EF не будет повторно создавать ее.

Наша задача — только определить модель, которая будет храниться в базе данных, и класс контекста. Поэтому данный подход называется Code First —
сначала пишется код, а потом по нему создается база данных и ее таблицы.

Введение в EF

Перед углублением в тему производительности было бы полезно вспомнить что такое EF и описать некоторые аспекты его работы, которые помогут нам в понимании разных подходов к оптимизации. Итак, EF это object-relational mapper (ORM) или инструмент, связывающий объектную модель, с которой мы работаем в коде (C# классы, коллекции, свойства) с реляционной моделью базы данных (таблица, столбец, запись, связи etc). Основной объект, который предоставляет EF для работы с базой данных это класс производный от DbContext. Класс содержит в себе набор объектов-коллекций DbSet, которые чаще всего соотносятся с таблицами базы данных. Для доступа к этим данным, мы обращаемся к этим коллекциям с помощью LINQ запросов, которые за кадром транслируются в SQL при вызове методов ToArray, ToList, FirstOrDefault и т.д., и работаем с данными также, как и с обычными C# объектами.

То, как работает, EF дает разработчикам несколько преимуществ. Во-первых, EF берет на себя ответственность за формирование корректных и безопасных от SQL инъекций запросов к базе данных для конкретного провайдера, используя строго типизированные LINQ запросы. Один и тот же C# код будет работать с MSSQL, Oracle и MySQL. Разработчик в большинстве случаев полностью абстрагируется от работы с SQL синтаксисом и может сосредоточиться на логике приложения. Во-вторых, EF предоставляет механизм, который отслеживает изменения свойств объектов (change-tracking) и позволяет при фиксации формировать Update и Delete запросы в базу данных, также без написания разработчиком какого либо SQL кода. Например:

EF имеет богатый функционал, значительно облегчающий разработку, однако это имеет свою цену и каждый этап обработки перед отправкой SQL запроса в базу данных и после получения ответа требует ресурсов. Попробуем составить упрощенную поэтапную схему работы EF от написания LINQ запроса, до получения данных.

Как видим между созданием DbContext, вызовом ADO NET и получением результатов в коде выполняется множество операций, которые потребляют ресурс процессора, создают объекты и сохраняют ссылки на них, нагружая GC, заполняют и очищают внутренние кэши и т.д. Dapper в свою очередь представляет собой минимальную прослойку между ADO NET и клиентским кодом, лишенную всех преимуществ EF, но от этого имеющую значительное преимущество по производительности. Для наглядности приведем пример кода с использованием Dapper:

В этой публикации хочу поделиться личным опытом использования Entity Framework (EF) в реальном приложении и дать несколько полезных советов использования данного фреймворка.

Я занимаюсь разработкой enterprise приложений на платформе . NET больше 7 лет, за это время перепробовал несколько ORM библиотек, но сейчас для новых проектов использую Entity Framework Code First.

Изначально, как следует из названия, данный подход предполагал, что база данных, хранящая данные приложения, описывается сначала с помощью кода, а затем фреймворк сам создает или обновляет её. Однако многие разработчики предпочли использовать прямо противоположный подход, когда сначала создается база данных, а затем уже к ней мапятся объекты. Это особенно удобно для enterprise приложений, где данные почти всегда ставятся во главу угла и используется довольно продвинутая СУБД типа Oracle или MSSQL Server. Мне не нравится дизайнер EF, когда в нем количество таблиц переваливает за сотню. Поэтому Code First был воспринят лично мной как нечто безумно удобное и крайне полезное.

Еще раз хочу повторить, что, на мой взгляд, в enterprise приложении главное — это данные, а не ваше приложение. Приложения приходят и уходят, заменяются на более новые, а данные остаются и используются годами. Поэтому в любом моем приложении база данных всегда создается проектировщиком базы данных, а не моим приложением.

Первое, что нужно сделать, если у вас уже есть готовая база данных — это создать классы, которые бы соответствовали таблицам. Вручную это делать очень утомительно, поэтому:

Совет №1. Генерация класса на основе таблицы

Cкрипт T-SQL, который можно взять отсюда, реально работает и очень удобен.

Совет №2. Прегенерация view

EF известен очень долгим временем обработки первого запроса на получение и сохранение данных. Для того, чтобы исправить эту ситуацию, можно использовать прегенерацию view.

Прегенерация view — это нечто, что происходит внутри фреймворка при выполнении первого запроса. Этот процесс можно перенести на этап компиляции вашего приложения, что существенно сократит скорость выполнения первого запроса. Для разных версий EF способы несколько отличаются. Я использовал этот подход и полностью остался им доволен.

Совет №3. Массовое обновление данных с помощью DetectChanges

По умолчанию фреймворк настроен на то, чтобы автоматически отслеживать изменения, которые затем нужно будет сохранить в базу данных.
Например, рассмотрим такой простой пример:

Запустив его, многие наверняка будут удивлены, что основное время будет потрачено не собственно на запрос к базе данных, а на вставку объектов в сам dbContext. Дело в том, что при изменении данных внутри DbContext-а происходит масса проверок и других малоизученных вещей, подробнее о которых можно прочесть здесь. Чтобы этого избежать можно отключить слежение за изменениями в классе DbContext, а затем явно вызвать метод DetectChanges(), который сам эти изменения обнаружит. Так, данный код будет работать значительно быстрее:

Совет №4. Следите за sql-запросами, которые формирует фреймворк

Это довольно универсальный совет, применимый, наверное, ко всем ORM, но многие почему-то о нем забывают. И после внедрения приложения, открыв профайлер и увидев 50 запросов к БД для показа довольно простой формы, бывают крайне удивлены.

Между тем, фреймворк предлагает механизмы для некоторой оптимизации. Среди этих механизмов наиболее известный — метод Include, который «вытягивает» дочерние объекты в том же запросе. Например:

Совет №5. Изолируйте логику работы с базой данных

Хотя в названии EF есть слово «фреймворк», его можно использовать и как обычную библиотеку просто для упрощения работы с базой данных.
В большинстве книг и презентаций мы видим код, похожий на этот:

Проблема этого кода в том, что он плотно привязывает все части приложения к Entity Framework. Это не хорошо и не плохо само по себе, но при этом вы должны понимать, что существенно осложняете себе жизнь, если архитектуру доступа к данным придется менять. А вариантов тут может быть масса:

Мне нравится подход, когда EF используется ТОЛЬКО внутри проекта с названием DAL (DataAccess и т.п.) в классах с названием Repository, например:

Этот подход хорош тем, что ваше приложение будет знать только о ваших объектах и о том, как их можно получить из БД и как сохранить в БД. Поверьте, этим вы существенно облегчите себе жизнь.

Отключение внутренних проверок потокобезопасности

DbContext в Entity Framework Core, в отличие от версии для Framework, не поддерживает сценарии работы с несколькими потоками. Для поддержки этого ограничения в EF присутствуют внутренние проверки, которые обнаруживают доступ из нескольких потоков и с помощью понятного исключения уведомляют программиста о неправильном использовании. Однако когда ваше приложение многократно проверено в проде, вы полностью уверены, что ошибок с многопоточностью у вас нет и вы используете DbContext правильно, стоит ли рассматривать эти проверки как накладные расходы, которые можно сократить ? Все рассмотренные выше рекомендации могут создавать определенный дискомфорт при разработке и имеют свои ограничения, однако ни одна из них не ставит под угрозу корректность и работоспособность EF. Отключение кода проверяющего корректное использование DbContext может иметь непредсказуемые последствия, о чем прямо предупреждается в документации к EF:

WARNING: Only disable thread safety checks after thoroughly testing that your application doesn’t contain such concurrency bugs.

Однако в контексте данной статьи и перечисления способов повышения производительности для EF стоит упомянуть что возможность отключить проверки потокобезопасности в DbContext есть. Для этого нужно вызвать соответсвующий метод в месте вызова AddDbContext:

Данная конфигурация, так же как и другие, была проверена с помощью BenchmarkDotNet, однако из всех опробованных улучшений показала минимальное влияние на производительность. К сожалению, цифру в 5 процентов прироста производительности, указанную в одной из issue на Github, мне повторить не удалось. Применять ли эту опцию в ваших продуктах — решать вам.

System Under Test (SUT)

Для демонстрации и сравнения нам понадобится веб API, которое будет взаимодействовать с тестовой SQL базой AdventureWorks, реализуя несколько часто встречающихся сценариев:

Нам понадобится реализовать API несколько раз, используя разные имплементации IProductsRepository на базе EF или Dapper для доступа к данным. Для полноценного нагрузочного тестирования мы будем использовать NBomber поочередно для всех перечисленных сценариев. Подробнее о NBomber и работе с ним можно ознакомится в этой статье. Для более быстрых локальных тестов в некоторых случаях мы будем использовать BenchmarkDotNet сценарии, которые будут повторять наше API в миниатюре, вызывая разные реализации интерфейса IProductsRepository для EF, Dapper и вариаций EF с различными улучшениями:

После того как мы рассмотрим все рекомендации по улучшению производительности работы EF, мы проведем еще один NBomber тест с примененными улучшениями и после сможем сделать выводы. Весь код использованный в данной статье доступен в репозитории на Github.

Перед началом улучшений проведем замер для Dapper и версии EF «из коробки». Для теста запустим поочередно обе версии приложения и проведем последовательное нагрузочное тестирование для каждого из сценариев, используя 30 тестовых клиентов, безостановочно шлющих запросы.

EF Default and Dapper

Как видим в данной конфигурации EF на 19-30 процентов уступает Dapper в большинстве сценариев для чтения, и значительно уступает в сценариях создания и редактирования. Теперь мы имеем точку отсчета и можем приступить к работе над улучшениями.

Пре-компиляция LINQ выражений в SQL

Несмотря на ожидаемые преимущества от применения такого подхода, а именно уменьшение аллокаций и уменьшение использования CPU, стоит отметить и недостатки. Во-первых, как можно заметить из примера, код стал значительно менее удобен для чтения. Во-вторых, для использования этого подхода вам необходимо затратить значительно больше времени чем на добавление AsNoTracking, особенно для переписывания и тестирования уже существующего кода. Отдельно хотелось бы отметить, на мой взгляд, не очень подробную документацию данной возможности и немного запутанный интерфейс метода EF. CompileAsyncQuery. С имеющейся документацией можно ознакомиться по этой ссылке.

Влияние комбинирования улучшений на производительность

Мы рассмотрели основные рекомендации по повышению производительности EF от Microsoft, разобрали механизм их работы, а также возможные накладные расходы при применении. Приведем общий список рекомендаций:

Пришло время их скомбинировать и провести повторное тестирование нашей системы.

EF Default, EF Improved and Dapper

Согласно результатам тестирования всех трех версий приложения, мы видим что улучшения для EF позволили на 6-25 процентов улучшить результаты по сравнению с версией EF «из коробки». Также значительно сократился разрыв с Dapper и теперь Dapper превосходит EF в среднем на 1.5-4.2 процента в большинстве сценариев на чтение.

К сожалению, мы также увидели что получить схожую с Dapper производительность для сценариев с редактированием и созданием, при этом сохраняя изоляцию C# программиста от SQL кода, увы не выйдет. Dapper все еще превосходит EF на 76 процентов в редактировании и на 74 процента в создании. Однако стоит отметить что EF конечно же дает программисту возможность вручную писать SQL код с помощью DbContext. Database. ExecuteSqlRaw. Таким образом вы сможете оптимизировать узкое место, не подключая при этом сторонних библиотек кроме EF. Результаты бенчмарка показывают что производительность EF ExecuteSqlRaw почти идентична коду, написанному на Dapper для обоих сценариев:

Стоит также добавить что в дорожной карте для следующей версии EF планируется провести оптимизацию change-tracking механизма и улучшить производительность сценариев Insert и Update:

For EF7, we plan to focus on performance related to database inserts and updates. This includes performance of change-tracking queries, performance of DetectChanges, and performance of the insert and update commands sent to the database.

Мы можем следить за ходом разработки на Github и надеяться что со следующим релизом разрыв с Dapper в этих сценариях будет существенно сокращен.

Отключение отслеживания изменений в объектах для read-only запросов

Рассматривая особенности работы EF мы упоминали систему отслеживания изменений. Change-tracking позволяет нам обновлять данные трансформируя изменения свойств объектов в SQL Update операции. Эта система включена по умолчанию для всех запросов, однако она имеет смысл только тогда, когда мы собираемся что-то редактировать. В сценариях только для чтения, эта система только создает дополнительные расходы. К счастью, ее можно отключить для конкретного запроса, вызвав метод AsNoTracking.

За пару лет я завел себе привычку всегда писать запросы через AsNoTracking, потому что запросы только для чтения приходится писать чаще чем запросы для редактирования. Однако если такой привычки у вас нет то вам необходимо будет выполнить некий объем работы, чтобы проанализировать свой код доступа к данным, выделить запросы только для чтения, добавить AsNoTracking и провести тестирование, чтобы убедится что никакие сценарии редактирования не сломались.

Стоит также добавить что поведение запросов по умолчанию в EF можно настроить таким образом, что все запросы будут повторять поведение AsNoTracking без явного вызова этого метода. Настроить это можно в месте вызова AddDbContext. Тогда вам наоборот придется явно добавлять вызов метода AsTracking в тех сценариях, где необходимо что-то отредактировать.

Использование DbContext. Entry для редактирования

Отдельно стоит выделить и разобрать результат тестирования сценария редактирования (Edit product), в котором Dapper превосходит EF более чем в 2 раза. Такой результат очень просто объяснить, взглянув на код редактирования в версии IProductsRepository для EF:

Для выполнения редактирования с помощью C# нам необходимо сначала получить объект, выполнив запрос в базу данных, модифицировать его и вызвать SaveChanges, что отправит еще один запрос в базу данных. Двукратное превосходство Dapper объясняется тем, что EF для редактирования с использованием C# необходимо отправлять в 2 раза больше запросов. Однако в EF есть еще один способ редактирования с использованием C#, который позволяет выполнить всего один запрос. Для этого нам необходимо вручную создать экземпляр Product, присвоить ему нужные свойства и вручную отредактировать состояние объекта в системе отслеживания изменений, при необходимости выбирая только те свойства, которые мы хотим поменять. В нашем случае мы собираемся менять только название:

DbContext pooling

Для повышения производительности при работе с EF нам необходимо постепенно уменьшать влияние промежуточных этапов которые мы описали ранее, уменьшая количество аллокации, повторных вычислений и по возможности делая часть вычислений наперед (pre-calculation). Microsoft предлагает использовать пул для объектов типа DbContext. Плюсы этого решения очевидны — переиспользование «тяжелых» объектов уменьшат давление на GC что будет заметно при интенсивной нагрузке. Также среди плюсов стоит отметить легкость в конфигурации — для настройки пулинга вам необходимо поменять лишь одну строку в конфигурации приложения, заменив вызов AddDbContext на AddDbContextPool в Program.cs. Ваш код доступа к данным (в нашем случае реализация IProductsRepository) останется нетронутым. Однако стоит учитывать что ваш DbContext по сути становится синглтоном и не должен сохранять никакого состояния между использованиями. Тем не менее если у вас возникает необходимость работать с данными scoped контекста, способ это сделать был предусмотрен и описан разработчиками EF. Также важно предусмотреть достаточно большой размер пула, так как при превышении его размера будут создаваться новые экземпляры DbContext.

Итоги

Как мы смогли увидеть, EF Core на момент июля 2022 года при правильном использовании может показывать результаты сопоставимые с Dapper для большинства сценариев для чтения, при этом сохраняя свои преимущества в виде генерирования корректного и безопасного SQL кода, используя строго типизированные LINQ выражения. Пока что EF все еще значительно уступает Dapper в Insert и Update сценариях при использовании C# обьектов для редактирования, но у разработчиков есть возможность при необходимости повысить производительность при помощи raw sql подхода. Мы можем ожидать уменьшение разрыва между EF и Dapper в этих сценариях уже в следующем релизе. На мой взгляд, и как показывает практика, EF Core последней версии вполне применим для использования в высоконагруженных системах. Учитывая богатый функционал, поддержку и популярность, а также то что EF Core и платформа NET не стоят на месте и с каждым релизом становятся лучше в плане производительности, вы не ошибетесь выбрав для разработки EF Core. Надеюсь что статья была вам полезна.

Спасибо за внимание !