Что такое Dapper и для чего он используется?

Ну что за дела, народ, опять про эти ваши ORM'ы спрашивают. Ладно, разберём по косточкам эту штуку под названием Dapper. Представьте, что Entity Framework — это здоровенный, навороченный комбайн, который сам пашет, сеет и жнёт, но бензина жрёт дохуя и иногда решает пахать не там, где вам надо. А Dapper — это как острая, наточенная сапёрная лопатка. Весит ничего, в руках лежит отлично, и копаешь ей ровно ту яму, которую задумал, и с бешеной скоростью.

Короче, это микро-ORM от тех самых ребят со Stack Overflow, которые знают толк в том, чтобы серваки не легли от кривых запросов. Суть проста до безобразия: он берёт голый ADO.NET (IDbConnection), который все боятся, и делает с ним одну простую, но гениальную вещь — превращает результаты SQL-запроса в ваши классы на C#. И всё. Никакого лишнего шаманства.

Смотрите, как это выглядит в жизни:

using Dapper;
using System.Data.SqlClient;

// Допустим, есть у нас класс пользователя, обычный такой, ничем не примечательный
public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}

string connectionString = "ВашаСтрокаПодключенияБлять";

using (var connection = new SqlConnection(connectionString))
{
    // Всё, магия начинается. Query<T> — это наш волшебный пинок под зад.
    // Кидаешь ему SQL и параметры, а он возвращает тебе готовых юзеров, а не какие-то DataTable.
    var activeUsers = connection.Query<User>(
        "SELECT Id, Name, Email FROM Users WHERE IsActive = @IsActive",
        new { IsActive = true } // Смотрите-ка! Параметры через анонимный объект. Удобно и от инъекций защищает.
    );

    foreach (var user in activeUsers)
    {
        Console.WriteLine($"{user.Name} ({user.Email})");
    }

    // А если надо что-то записать, удалить или обновить — Execute в помощь.
    // Никакого трекинга, SaveChanges() и прочей мишуры. Сказал — сделал.
    var rowsAffected = connection.Execute(
        "UPDATE Users SET LastLogin = @Now WHERE Id = @Id",
        new { Now = DateTime.UtcNow, Id = 42 }
    );
}

Почему это, блядь, может быть круто:

• Скорость, ядрёна вошь! Он быстрее многих, потому что не грузит в себя тонны фич, которые вам, возможно, и не нужны. Почти как голый ADO.NET, но без боли в пальцах от вечного маппинга.
• Прозрачность. Вы видите каждый SQL-запрос, который улетает в базу. Никаких сюрпризов вроде "N+1 Query Problem", который EF может незаметно устроить. Сам написал запрос — сам и виноват, если он кривой.
• Гибкость. Хочешь — JOIN'ы пяти таблиц пили, хочешь — хранимую процедуру вызови, хочешь — результат в какую-нибудь замудрённую вью-модель сложи. Dapper не будет морщиться и говорить "модель данных не соответствует".

Но и подводные камни, куда без них:

• Нет миграций. Это же не полноценный ORM, чувак. Структуру базы (таблицы, индексы) тебе самому надо обновлять. Через отдельные скрипты, DbUp, Flyway — что душе угодно.
• Нет трекинга изменений. Объект после выборки — он просто данные. Изменил свойство — и нихуя не произошло. Чтобы обновить запись в базе, ты должен явно вызвать Execute с UPDATE-запросом. Сам.
• Больше рутины. SQL писать надо на каждую операцию. Для кого-то это плюс (контроль!), для кого-то — минус (работы больше).

Так что в итоге-то? Если твой проект — это высоконагруженное API, где каждый миллисекунд на счету, или там сплошная аналитика с дикими запросами, или ты просто терпеть не можешь, когда ORM делает что-то за тебя без спроса — Dapper твой выбор. Это инструмент для взрослых дядек, которые знают SQL и хотят, чтобы всё летало.

Если же тебе нужно быстро накодить бизнес-приложение с кучей связей, где структура базы постоянно меняется, и ты не хочешь заморачиваться с SQL — иди в Entity Framework Core. Там тебе и миграции, и трекинг, и LINQ.

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