.NET 6 и провайдеры баз данных

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

Можно ли сегодня представить разработку, будь то десктопы или веб, без использования баз?

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

В чем же так плоха файловая система? Ну на самом деле, говоря на своем опыте, можно выделить следующие пункты:

1. Блокировка файла, в который идет запись

2. Отсутствие специализированных программ для работы с файлами (аналог СУБД)

Да, в какой-то мере можно выделить еще минусы, или попытаться закрыть уже названные мной. Но в целом главная идея базы данных – это удобство для чтения данных, а также наличие огромного числа инструментов для работы с данными (возможность быстрого поиска по полям таблицы, соединение таблиц, группировка записей, индексирование и т.д.)

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

Говоря о базах, я упомянул понятие запросов. В общих чертах запрос – это команда, которую ты говоришь выполнить базе. Запросы пишутся на языке SQL, состоят из предложений, и вот основные из них:

• SELECT

• FROM

• JOIN

• WHERE

• GROUP BY

• HAVING

• ORDER BY

Для данной статьи будем использовать базу данных состоящую из 3 таблиц:

dbo.Student

• Id

• Name

• Course

• BirthDate

dbo.Department

• Id

• Name

dbo.Coursework

• Id

• StudentId

• DepartmentId

• DeliveryDate

-- SELECT указывает на то, какие поля мы хотим выбрать.  -- Если указать *, то это означает выбор всех полей. SELECT Student.Name, Student.BirthDate, COUNT(*) AS [Количество курсовых] -- FROM указывает на то, из какой таблицы мы хотим вытащить данные FROM Student -- JOIN предназначен для объединения таблиц по какому либо условию. -- В данном случае мы делаем связь по айдишникам студентов. JOIN Coursework ON Student.Id = Coursework.StudentId -- WHERE позволяет фильтровать выбору по какому либо условию . -- Так, в этом случае я ищу тех студентов, которые имеют в имени начало Vladzimir. WHERE Student.Name LIKE 'Vladzimir%' -- GROUP BY нужен для группировки выборки, в данном случае группируем по студентам,  -- чтобы найти сколько у каждого студента сдано курсовых. GROUP BY Student.Name, Student.BirthDate -- HAVING представляет собой вторичную фильтрацию, и используется после GROUP BY. -- В данном случае нам интересны те студенты, у которой больше 1 курсовой работы. HAVING COUNT(*) > 1 -- ORDER BY служит для сортировки. Так, мы сортируем по убыванию -- по полю день рождения. -- Для сортировки по возрастанию надо убрать ключевое слово DESC. ORDER BY BirthDate DESC

Отлично! Итого мы получаем всех студентов и количество их курсовых, если их сдано больше 1. Также нас интересуют только те студенты, у которых имя начинается с Vladzimir. При этом для удобства отсортировали по убыванию даты рождения.

Немного практики с SQL и он уже не кажется таким страшным и сложным. Хотя практиковаться с ним надо много, так как существует запросы куда больше и сложнее.

Теперь хорошая возможность перейти к нашей разработке.. Как же нам подружить наше приложение с базой данных?

Первое с чем надо определиться — это сервер и непосредственно наша база. Если мы пользуемся СУБД, то узнать данные параметры очень легко:

В данном случае, так как я пользовался MS SQL Server, то использовать Microsoft SQL Server Managment Studio (SSMS) является лучшим решением. При использовании, допустим, PostgreSQL можно использовать PG Admin в качестве СУБД.

При установке SQL сервера, в зависимости от версии (Express или расширенная) будет доступно несколько серверов: 

{Имя компьютера}\SQLEXPRESS,  

{Имя компьютера}. 

Также отдельно можно поставить (localdb)\MSSQLLocalDB.

Теперь, определившись с сервером и базой данных (название можно придумать какое угодно, но для примеров ниже база будет называться University), можно приступать к изучению платформы .NET.

На самом деле на платформе .NET есть три основных решения для данной ситуации (в реальности их будет и больше, скорее всего, но реально поддерживаемых, стабильных и проверенных только три).

Поговорим немного о теории.

У нас есть 3 основных понятия, от которых и будет опираться:

1. ORM — это расшифровывается как Object/Relational Mapping, предоставляет большой перечень работы с базой, и базовые удобства, например как, CRUD операции из под коробки, также поддержка Change Tracker, Unit of Work и т.д.

2. Micro-ORM — представляет собой возможность сопоставления данных из таблиц с классами C#. На этом всё.

3. Провайдер базы данных — предоставляет возможность установить соединение с базой данных и отправить туда запрос. Всё остальное лежит на плечах программиста.

Поэтому, когда говорим об ADO.NET — это провайдер, EntityFramework (EF) — ORM, а Dapper — micro-ORM.

ADO.NET

Необходимо наличие следующих пакетов:

• System.Data.SqlClient

Первым, и главным столпом является ADO.NET. Данный посредник между приложением и базой данных является самым старым, и предоставляет наибольшую свободу при работе с данными. Что предоставляет нам данная технология? На самом деле не так много, он позволяет открыть соединение с базой, и возможность отправки запроса в базу, а дальше.. Ну делайте что хотите в общем, его это уже не касается. В связи с этим большая необходимость в том, чтобы самим отлавливать все исключения, и самим закрыть соединение с базой после выполнения запроса (да, для особо ленивых придумана конструкция using еще).

Основные классы, используемые для работы с ADO.NET:

• SqlConnection

• SqlCommand

• SqlDataReader

• SqlParameter

Так, напишем консольное приложение, для того, чтобы попробовать работу с ADO.NET:

Первое, что мы делаем — создаем объект класса SqlConnection, в который передаем connectionString, эта переменная в которой содержится строка подключения к нашей базе

В моем случае она будет такая:

var connectionString =    "Data Source=.\\SQLEXPRESS;Initial Catalog=University;Integrated Security=True";

// Объявлем соединение с определенной строкой подключения. var sqlConnection = new SqlConnection(connectionString);

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

try {     sqlConnection.Open();     Console.WriteLine("SQL соединение открыто.");      // Добавление (аналогичный код для обновления / удаления).     var sqlCommand = sqlConnection.CreateCommand();     sqlCommand.CommandText = "INSERT INTO Student VALUES ('TestUser', 1, '20220101')";     var affectedRows = sqlCommand.ExecuteNonQuery();     Console.WriteLine($"Число затронутых строк: {affectedRows}");      // Чтение.     var sqlCommandForRead = sqlConnection.CreateCommand();     sqlCommandForRead.CommandText = "SELECT * FROM Student";     SqlDataReader reader = sqlCommandForRead.ExecuteReader();      if (reader.HasRows)     {         while (reader.Read())         {             // При использовании reader[""] - мы получаем object,             // если хотим конкретный тип,             // то используем reader.GetString() / reader.GetInt() и т.д.             Console.WriteLine($"Студент с Id: {reader["Id"]}, " +                 $"с курсом: {reader["Course"]}, " +                 $"с именем: {reader["Name"]}, " +                 $"с датой рождения: {reader["BirthDate"]}");         }     }      reader.Close();      // Получение результата агрегатной функции     var sqlCommandForCount = sqlConnection.CreateCommand();     sqlCommandForCount.CommandText = "SELECT COUNT(*) FROM Student";     var count = sqlCommandForCount.ExecuteScalar();     Console.WriteLine($"Полное число студентов: {count}");      // Есть два варианта параметризации запросов.     var name = "Some Student Name";      // Плохой вариант, так как позволяет получать и изменять данные      //при помощи механизма SQL-инъекций.     var sqlString = $"INSERT INTO Student VALUES ('{name}', 1, '20220101')";      var sqlCommandForInsertBadPractice = new SqlCommand(sqlString)     {         Connection = sqlConnection     };      affectedRows = sqlCommandForInsertBadPractice.ExecuteNonQuery();      // Хороший вариант, добавление SQL параметров.     sqlString = $"INSERT INTO Student VALUES (@name, 1, '20220101')";     var sqlParamForName = new SqlParameter("@name", name);     var sqlCommandForInsertGoodPractice = new SqlCommand(sqlString);      // Добавление параметра.     sqlCommandForInsertGoodPractice.Parameters.Add(sqlParamForName);     affectedRows = sqlCommandForInsertBadPractice.ExecuteNonQuery(); } catch (Exception ex) {     Console.WriteLine($"Ошибка: {ex.Message}");     throw; } finally {     sqlConnection.Close();     Console.WriteLine("SQL соединение закрыто."); }

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

1. Пишем конструкцию try catch finally

2. В try открываем соединение, в finally его закрываем

3. Затем происходит выбор: что нам нужно — чтение или изменение?

Так, в случае изменения данных создается экземпляр класса SqlCommand, затем указывается SQL запрос и выполняется метод ExecuteNonQuery(), который возвращает нам число затронутых строк:

var sqlCommand = sqlConnection.CreateCommand(); sqlCommand.CommandText = "INSERT INTO Student VALUES ('TestUser', 1, '20220101')"; var affectedRows = sqlCommand.ExecuteNonQuery(); Console.WriteLine($"Число затронутых строк: {affectedRows}");

В данном случае мы делаем вставку 1 записи, а значит на консоли увидим, что число затронутых строк также ровно 1.

В случае чтения данных необходимо создать также создать создать команду, однако вместо того, чтобы вызвать ExecuteNonQuery(), надо будет вызвать ExecuteReader(), который вернет нам экземпляр SqlDataReader.

var sqlCommandForRead = sqlConnection.CreateCommand(); sqlCommandForRead.CommandText = "SELECT * FROM Student"; SqlDataReader reader = sqlCommandForRead.ExecuteReader();

После получения данного экземпляра, проверяем, вернул ли он какие-то либо строки, и если вернул, то тогда начинаем их читать

if (reader.HasRows) {   while (reader.Read())   {     // При использовании reader[""] - мы получаем object,     // если хотим конкретный тип,     // то используем reader.GetString() / reader.GetInt() и т.д.     Console.WriteLine($"Студент с Id: {reader["Id"]}, " +                       $"с курсом: {reader["Course"]}, " +                       $"с именем: {reader["Name"]}, " +                       $"с датой рождения: {reader["BirthDate"]}");   } }

После того, как мы выйдем из цикла while — обязательно закрываем reader.

reader.Close();

В случае необходимости получения данных путем вычисления агрегатной функции (COUNT, MIN, MAX, AVG, SUM) — применяют метод ExecuteScalar(), который возвращает первый столбец первой строки (чтоб в целом нам и нужно).

var sqlCommandForCount = sqlConnection.CreateCommand(); sqlCommandForCount.CommandText = "SELECT COUNT(*) FROM Student"; var count = sqlCommandForCount.ExecuteScalar(); Console.WriteLine($"Полное число студентов: {count}");

Теперь переходим наверное к самому интересному, а именно параметризация запросов.

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

Пусть у нас будет переменная name, содержащая некоторую строку:

var name = "Some Student Name";

Интерполяция строк

К плюсам этого способа можно выделить более простой способ написания, который просто встраивает переменные в строку при помощи интерполяции строк

var sqlString = $"INSERT INTO Student VALUES ('{name}', 1, '20220101')";  var sqlCommandForInsertBadPractice = new SqlCommand(sqlString) { Connection = sqlConnection };  affectedRows = sqlCommandForInsertBadPractice.ExecuteNonQuery();

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

SQL-параметры

Тут ситуация гораздо лучше и не пропускает невалидные ситуации, которые могут быть в ситуации выше, однако приходится написать больше кода:

sqlString = $"INSERT INTO Student VALUES (@name, 1, '20220101')"; var sqlParamForName = new SqlParameter("@name", name); var sqlCommandForInsertGoodPractice = new SqlCommand(sqlString);  sqlCommandForInsertGoodPractice.Parameters.Add(sqlParamForName); affectedRows = sqlCommandForInsertBadPractice.ExecuteNonQuery();

На этом основные возможности ADO.NET заканчиваются. В целом основная идея — следит за ошибками со стороны провайдера, и писать SQL код.

Dapper

Необходимо наличие следующих пакетов:

• Dapper

• System.Data.SqlClient

Много лишней теории тут говорить не буду. В целом Dapper — это посредник, которому всё еще нужен SqlConnection, однако открытие и закрытие уже будет автоматическим и в общем случае будет использоваться оператор using. Также один из важных плюсов Dapper — это сопоставление результатов запроса с классами C#, а значит не придется не придется делать страшные манипуляции с reader, как это было в случае с ADO.NET

Классы, используемые при работы с Dapper

• SqlConnection

И используемые от него методы: .Query<T>() и .Execute().

Чтобы долго не тянуть — перейдем сразу к написанию консольного приложения по работе с Dapper:

using (var sqlConnection = new SqlConnection(connectionString)) {     // Добавление (аналогичный код для обновления / удаления).     sqlConnection.Execute(       "INSERT INTO Student VALUES ('TestUserDapper', 1, '20220101')"     );      // Чтение данных.     var students = sqlConnection.Query<Student>("SELECT * FROM Student").ToList();      foreach (var student in students)     {         Console.WriteLine($"Студент с Id: {student.Id}, " +             $"с курсом: {student.Course}, " +             $"с именем: {student.Name}, " +             $"с датой рождения: {student.BirthDate}");     }      // Получение результата агрегатной функции     // В данном случае необходимо использование .FirstOrDefault(), так как     // .Query<T> возвращает IEnumerable<T>, что является коллекцией.     // И так как мы знаем что результатом будет 1 запись, то без зазрений совести     // можем применить .FirstOrDefault(), чтобы получить число записей.     var count = sqlConnection.Query<int>("SELECT COUNT(*) FROM Student")        .FirstOrDefault();      Console.WriteLine($"Общее число записей в таблице студентов: {count}");      // Использование параметров.     sqlConnection.Execute("INSERT INTO Student VALUES (@Name, @Course, @BirthDate)",          new Student         {              Name = "SomeParamName",              Course = 2,              BirthDate = new DateTime(2022, 04, 04)         });      // Анонимные объекты new { }.     sqlConnection.Execute("DELETE FROM Student WHERE Name = @name",          new { name = "TestUserDapper" }); }

Даже сравнивания по объему кода уже видно, насколько Dapper проще в использовании.

В целом использование у Dapper следующее:

1. В конструкции using создать экземпляр SqlConnection с переданной в него строкой подключения

2. В зависимости от того, хотим ли получить данные, или их изменить — написать .Query<T> или .Execute

При чтении данных мы используем .Query<T>, где T — класс, в который будут мапиться результатами из базы. Так, вся работа которую мы делали руками, получая каждое значение каждой строки руками — Dapper делает за нас, и на выходе мы получаем IEnumerable<T>.

var students = sqlConnection.Query<Student>("SELECT * FROM Student").ToList(); // В случае единственного перечисления по коллекции students приведение к ToList()  // является избыточным и сделано только в учебных целях.

Для получения результата агрегатной функции в общем случае используется также Query<T>, где в T передается тип данных (int, double, float и т.д), а затем берется первая запись из полученной коллекции, так как такая выборка на стороне базы возвращает 1 строку с 1 столбцом.

var count = sqlConnection.Query<int>("SELECT COUNT(*) FROM Student")        .FirstOrDefault();

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

Так, например, при добавлении записи мы можем написать следующую запись:

sqlConnection.Execute("INSERT INTO Student VALUES (@Name, @Course, @BirthDate)",          new Student         {              Name = "SomeParamName",              Course = 2,              BirthDate = new DateTime(2022, 04, 04)         });

Dapper сам произведет необходимый маппинг по имени. Если типы не соответствует — будет выброшено исключение.

И пример использования анонимного объекта, если не хотим создавать какой-то класс:

sqlConnection.Execute("DELETE FROM Student WHERE Name = @name",          new { name = "TestUserDapper" });

На этом основные возможности Dapper заканчиваются. Он прост в использовании, и как посмотрим далее, достаточно производителен.

EntityFramework

Необходимо наличие следующих пакетов:

• Microsoft.EntityFrameworkCore

• Microsoft.EntityFrameworkCore.SqlServer

• Microsoft.EntityFrameworkCore.Tools (Не обязательный)

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

Вот несколько сильных сторон от EF:

1. Поддержка разных способов синхронизации (Code First, Database First)

2. Миграции

3. LINQ To Entities (и расширения напрямую из пакета EntityFrameworkCore)

4. AsNoTracking

5. CRUD операции

Начнем с самого начала — EF является достаточно большой системой, которая требует много подготовительной работы, но сполна награждает за неё. Так, например, создадим все классы для нашей базы данных (Student, Department, Coursework):

public class Student {   public int Id { get; set; }    public int Course { get; set; }    [StringLength(90)]   public string Name { get; set; }    public DateTime BirthDate { get; set; } }  public class Department {   public int Id { get; set; }    [StringLength(90)]   public string Name { get; set; } }  public class Coursework {   public int Id { get; set; }    public int StudentId { get; set; }    public int DepartmentId { get; set; }    public DateTime DeliveryDate { get; set; } }

После создания данных классов (что в целом достаточно легко), нам необходимо создать её один класс — который обычно называется — НазваниеБазыContext, так в данном случае это будет UniversityContext.

public class UniversityContext : DbContext { public UniversityContext() { } public UniversityContext(DbContextOptions options) : base(options) { }  public DbSet<Student> Student { get; set; }  public DbSet<Department> Department { get; set; }  public DbSet<Coursework> Coursework { get; set; }  protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)   {   var dbConfig = new DbConfiguration(); optionsBuilder.UseSqlServer(dbConfig.GetConnectionString("connString"));   } }

Тут уже немного сложнее, поэтому пройдемся более детально по этому классу.

Наличие DbSet<T>. В целом, для простого понимания — DbSet представляет собой коллекцию (но не в памяти, а удаленную), которая представляет каждую отдельную таблицу. Так, например, DbSet<Student> Student — говорит о том, что у нас «есть» таблица со столбцами такими как поля в классе Student, и название у такой таблицы Student.

Также есть переопределение метода OnConfiguring(DbContextOptionsBuilder optionsBuilder). Это нужно для того, чтобы определить, с какой базой данный будет связан наш контекст. В целом там гораздо больше различных настроек, но на данный момент это основная.

Немного про конструкторы: в данном случае их 2, хотя для наших целей достаточно и одного. В общем случае при разработке веб-приложений и использования механизма DI нам будет достаточно второго конструктора, который принимает параметры. Однако в данном кейсе мы делаем все настройки в методе OnConfiguring, поэтому нам достаточно просто создавать контекст с пустым конструктором. Но не всё так просто.

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

• Иметь конструктор без параметров

• Иметь класс, который реализует интерфейс IDesignTimeDbContextFactory<T>, где T — наш контекст. Вот пример реализации этого интерфейса:

public class UniversityContextFactory :  IDesignTimeDbContextFactory<UniversityContext> { public UniversityContext CreateDbContext(string[] args) { var dbConfig = new DbConfiguration(); var optionsBuilder = new DbContextOptionsBuilder<UniversityContext>(); optionsBuilder.UseSqlServer(dbConfig.GetConnectionString("connString"));  return new UniversityContext(optionsBuilder.Options); } }

Миграции

Миграции — магическое слово EF и одна из самых сильных его сторон. Что такое миграции?

Это механизм, который позволяет нам создать некоторое подобие гита, только для базы данных. Фактически, внося изменения в какую-нибудь из моделей или контекст, вы “фиксируете” эти изменения и создаете миграцию. Она имеет два метода: Up и Down. Соответственно при помощи данных методов вы можете двигаться “вверх” или “вниз”. Немало важный плюс миграций — это то, что они не удаляют данные, когда накатываются на базу. Работа с миграциями всегда будет идти по циклу: внесли изменения в C# классы, создали миграцию, применили миграцию.

Для создания миграции нам нужно открыть Package Manager Console в Visual Studio и написать следующую команду:

Add-Migration <Название Миграции>

В результате выполнения этой команды появится 2 класса (только при первой миграции, потом будет 1 класс).

Один из классов — ModelSnapshot, которую является некоторым сборщиком миграций, и знает, в каком порядке они должны применяться.

Второй класс — это непосредственно наша миграция и имеет данный класс следующий вид:

public partial class Initial : Migration     {         protected override void Up(MigrationBuilder migrationBuilder)         {             migrationBuilder.CreateTable(                 name: "Coursework",                 columns: table => new                 {                     Id = table.Column<int>(type: "int", nullable: false)                         .Annotation("SqlServer:Identity", "1, 1"),                     StudentId = table.Column<int>(type: "int", nullable: false),                     DepartmentId = table.Column<int>(type: "int", nullable: false),                     DeliveryDate = table.Column<DateTime>(type: "datetime2",                      nullable: false)                 },                 constraints: table =>                 {                     table.PrimaryKey("PK_Coursework", x => x.Id);                 });              migrationBuilder.CreateTable(                 name: "Department",                 columns: table => new                 {                     Id = table.Column<int>(type: "int", nullable: false)                         .Annotation("SqlServer:Identity", "1, 1"),                     Name = table.Column<string>(type: "nvarchar(90)",                      maxLength: 90, nullable: false)                 },                 constraints: table =>                 {                     table.PrimaryKey("PK_Department", x => x.Id);                 });              migrationBuilder.CreateTable(                 name: "Student",                 columns: table => new                 {                     Id = table.Column<int>(type: "int", nullable: false)                         .Annotation("SqlServer:Identity", "1, 1"),                     Course = table.Column<int>(type: "int", nullable: false),                     Name = table.Column<string>(type: "nvarchar(90)",                      maxLength: 90, nullable: false),                     BirthDate = table.Column<DateTime>(type: "datetime2",                      nullable: false)                 },                 constraints: table =>                 {                     table.PrimaryKey("PK_Student", x => x.Id);                 });         }          protected override void Down(MigrationBuilder migrationBuilder)         {             migrationBuilder.DropTable(                 name: "Coursework");              migrationBuilder.DropTable(                 name: "Department");              migrationBuilder.DropTable(                 name: "Student");         }     }

Как и говорилось выше — миграция имеет два метода, один применяется, если мы применяем нашу миграцию (то есть идем «вверх»), а второй применяется, когда мы отменяем миграцию (то есть идем «вниз»). Так, в нашем примере мы создали миграцию с именем Initial, и при применении миграции у нас появятся три таблицы, а при отмене миграции — удалятся 3 таблицы.

Можете попробовать удалить все таблицы из базы (даже саму базу), и ввести в Package Manager Console следующую команду:

Update-Database

После этого можете удивляться результату.

На самом деле, Миграции являются частью принципа Code First, в котором мы пишем код, а потом говорим, что EF применил этот код для базы. Однако существует и второй принцип — Database First, который, по названию, означает, что сначала мы создаем базу, а потом только C# код. На самом деле реализуется это достаточно простым механизмом, что называется одной командой, которая имеет следующий вид, и вводится в всё тот же Package Manager Console:

Scaffold-DbContext "Server=(localdb)\mssqllocaldb;Database=University;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer

И так, как и я сказал, это один из самых важных и популярных механизмов, который предоставляет EF, но не единственный.

LINQ To Entities

Еще одна классная возможность EF — поддержка построения запросов без знания SQL, так как EF сам делает все преобразования C# кода в SQL.

Например, если вернёмся к тому SQL скрипту, который был в самом начале:

SELECT Student.Name, Student.BirthDate, COUNT(*) AS [Количество курсовых] FROM Student JOIN Coursework ON Student.Id = Coursework.StudentId WHERE Student.Name LIKE 'Vladzimir%' GROUP BY Student.Name, Student.BirthDate HAVING COUNT(*) > 1 ORDER BY BirthDate DESC

На языке LINQ это будет выглядеть так:

var sqlQueryToLinq = dbContext.Student   .Where(student => student.Name.Contains("Vladzimir"))   .Join(dbContext.Coursework,          student => student.Id,          coursework => coursework.StudentId,          (student, coursework) => student)   .GroupBy(student => new { student.Name, student.BirthDate })   .Where(grouped => grouped.Count() > 1)   .OrderByDescending(grouped => grouped.Key.BirthDate)   .Select(grouped =>            new { grouped.Key.Name, grouped.Key.BirthDate, Count = grouped.Count() })   .ToList();

Выглядит сложно для первого понимания, но в целом любая часть соответствует предложениям из SQL. А трактовка значка ‘=>’ несколько сложная, если не понять что такое делегаты. Но если пояснение, то его можно посмотреть тут:

// Обращаюсь к базе данных, в частности к таблице Student dbContext.Student // Из всех студентов выбрать такого студента,  // у которого имя содержит "Vladzimir"   .Where(student => student.Name.Contains("Vladzimir")) // Сделать объединение с таблицей Coursework   .Join(dbContext.Coursework,  // Со стороны таблицы Student связь по полю Id         student => student.Id,  // Со стороны таблицы Coursework связь по полю StudentId         coursework => coursework.StudentId, // В результате объединения остальные данные только по студенту         (student, coursework) => student) // Сделать группировку по имени и дате рождения   .GroupBy(student => new { student.Name, student.BirthDate }) // Выбрать те записи группировки,  // у которых результат группировки больше 1 // (это мы про количество курсовых говорили)   .Where(grouped => grouped.Count() > 1) // Отсортировать записи по убыванию дня рождения   .OrderByDescending(grouped => grouped.Key.BirthDate) // Из результата группировки создать коллекцию анонимных обьектов, // состоящих из имени, дня рождения и количество курсовых   .Select(grouped =>            new { grouped.Key.Name, grouped.Key.BirthDate,                  Count = grouped.Count() }) // Команда выполнения запроса   .ToList();

AsNoTracking

Еще одна возможность EntityFramework, о которой немного подробнее надо рассказать:

Внутри EntityFramework содержится много разных способ отслеживания изменений, кеширования и т.д.

Так вот один из явных инструментов является Change Tracker, который создает некоторую связь между данными из таблиц и объектами C#. Также, если нам это механизм кажется излишним, то мы его может отключить, при помощи метода AsNoTracking().

Рассмотрим такой пример для большей наглядности этого механизма:

var studentVladzimir = dbContext.Student   .Where(student => student.Name.Contains("Vladzimir"))   .FirstOrDefault();  studentVladzimir.Course = 999; dbContext.SaveChanges();  var studentVladzimirWithoutTracking = dbContext.Student       .Where(student => student.Name.Contains("Vladzimir"))       .AsNoTracking()       .FirstOrDefault();  studentVladzimirWithoutTracking.Course = 777; dbContext.SaveChanges();

Что мы ожидаем увидеть в таблице, если найдем такую запись? Результат будет 999.

Почему так? Потому что когда мы получаем данные при помощи нашего контекста, то он не создаем полностью независимый объект, а ставит между ним и записью из базы связь, которая будет обновлять запись в базе при применении SaveChanges().

В случае применения AsNoTracking() — контекст не будет устанавливать связь, а просто создать новый объект, как будто сделали просто new Student().

CRUD-операции

Напоследок, небольшой бонус, который дает EF — готовые реализации для добавления, удаления и изменения записи.

Так, например, для добавления используется следующий код:

dbContext.Student.Add(   new Student()  {      Name = "SomeStudent For EF Test",      Course = 3,      BirthDate = new DateTime(2022, 4, 7)  });

Аналогичный код используется и для обновления (Update), и удаления (Remove).

Также, один из важных плюсов, поддержка — AddRange, UpdateRange, RemoveRange, они являются возможность делать bulk-операции.

Немного тестов и результаты

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

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

Так, например, вот такие результаты показали провайдеры на 20000 данных.

Как видим, EF показываем не самые лучшие результаты, и по большей части это связано с тем, что мы всячески блокируем в тестах попытки кеша каких либо результатов. В реальных условиях ситуация будет такая, что разница между Dapper и EF может быть до 5%. Однако тяжеловесность EF показывает то, как много памяти он кушает.

В большинстве своем — получение такого числа данных — очень редкий кейс, и в среднем надо вытягивать от 1 до 100 записей за раз, и на таких данных разница во времени будет минимальна между ними.

Вот некоторые выводы к которым можно прийти, прочитав эту статью:

1. .NET предоставляет различные механизмы работы, и выбор достаточно внушительный, каждый из представленных механизмов отличается от двух других.

2. Знание SQL необходимо, но не обязательно. Влияние EntityFramework с годами увеличивается, как и его производительность.

3. Мы всегда смотрим не только на производительность, но и на то насколько быстро мы можем написать наш код. В таких случаях зачастую выбор остается между Dapper и EntityFramework.

На этом наверное всё, огромное спасибо за прочтение этой статьи!

Как и говорилось в начале, вы можете попробовать сделать всё сами, при помощи github-репозитория, который будет в открытом доступе.