этот пост показывает, как запросить a сильно нормализованная база данных SQL, и сопоставить результат в набор сильно вложенных объектов C# POCO.

Ингредиенты:

• 8 строк C#.
• некоторые достаточно простой SQL, который использует некоторые соединения.
• две потрясающие библиотеки.

понимание, которое позволило мне решить эту проблему, состоит в том, чтобы отделить MicroORM С mapping the result back to the POCO Entities. Таким образом, мы используем два отдельных библиотеки:

• щеголеватый как MicroORM.
• гулящая.Automapper для отображения.

по сути, мы используем щеголеватый чтобы запросить базу данных, затем используйте гулящая.Automapper чтобы отобразить результат прямо в наши POCOs.

преимущества

• простота. Его менее 8 строк кода. Я нахожу это намного легче понять, отладка и изменение.
• меньше кода. Несколько строк кода-это все гулящая.Automapper нужно обрабатывать все, что вы бросаете на него, даже если у нас есть сложный вложенный POCO (т. е. POCO содержит List<MyClass1> что, в свою очередь, содержит List<MySubClass2> и т. д.).
• скорость. Обе эти библиотеки имеют экстраординарное количество оптимизации и кэширования, чтобы заставить их работать почти так же быстро, как ручная настройка ADO.NET запросы.
• разделение. Мы можем изменить Микроорм на другой, и отображение все еще работает, и наоборот.
• гибкость. гулящая.Automapper обрабатывает произвольно вложенные иерархии, это не ограничивается несколькими уровнями вложенности. Мы можем легко сделать быстрые изменения, и все будет работать.
• отладка. Сначала мы можем увидеть, что SQL-запрос работая правильно, мы можем проверить, что результат SQL-запроса правильно сопоставлен с целевыми объектами POCO.
• простота разработки в SQL. Я считаю, что создание сглаженных запросов с inner joins чтобы вернуть плоские результаты гораздо проще, чем создание нескольких операторов select, с прошивкой на стороне клиента.
• оптимизированные запросы в SQL. В сильно нормализованной базе данных создание плоского запроса позволяет применять механизм SQL расширенные оптимизации в целом, которые обычно не были бы возможны, если бы было построено и запущено много небольших отдельных запросов.
• доверие. Dapper-это задняя часть для StackOverflow, и, ну, Рэнди Берден немного суперзвезда. Мне нужно еще что-то сказать?
• скорость разработки. я был в состоянии сделать некоторые чрезвычайно сложные запросы, с большим количеством уровней вложенности, и время разработки было довольно низким.
• меньше жуки. я написал его однажды, он просто работал, и этот метод теперь помогает привести в действие компанию FTSE. Было так мало кода, что не было никакого неожиданного поведения.

недостатки

• масштабирование за пределы 1 000 000 строк возвращается. хорошо работает при возврате 1,000,000 строк, чтобы уменьшить трафик между нами и SQL server, мы не должны сглаживать его с помощью inner join (что возвращает дубликаты), мы должны вместо этого использовать несколько select заявления и сшить все вместе на стороне клиента (см. другие ответы на этой странице).
• этот метод ориентирован на запрос. Я не использовал этот метод для записи в базу данных, но я уверен, что Dapper более чем способен сделать это с некоторой дополнительной работой, так как StackOverflow сам использует Dapper в качестве своего уровня доступа к данным (DAL).

производительность Тестирование

в моих тестах, гулящая.Automapper добавил небольшие накладные расходы на результаты, возвращенные Dapper, что означало, что он все еще был в 10 раз быстрее, чем Entity Framework, и комбинация все еще довольно близка к теоретической максимальной скорости, на которую способен SQL + C#.

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

Результаты Испытаний

общее количество итераций: 1000

• Dapper by itself: 1.889 миллисекунд на запрос, используя 3 lines of code to return the dynamic.
• Dapper + Slapper.Automapper: 2.463 миллисекунды на запрос, используя дополнительный 3 lines of code for the query + mapping from dynamic to POCO Entities.

Работала

в этом примере у нас есть список Contacts и друг Contact может иметь один или более phone numbers.

сущностей Poco

public class TestContact
{
    public int ContactID { get; set; }
    public string ContactName { get; set; }
    public List<TestPhone> TestPhones { get; set; }
}

public class TestPhone
{
    public int PhoneId { get; set; }
    public int ContactID { get; set; } // foreign key
    public string Number { get; set; }
}

таблица SQL TestContact

таблица SQL TestPhone

обратите внимание, что эта таблица имеет внешний ключ ContactID что относится к TestContact таблица (это соответствует List<TestPhone> в POCO выше).

SQL, который дает плоский результат

в нашем SQL-запросе мы используем как можно больше JOIN заявления, как нам нужно получить все данные, которые нам нужны, в квартиры, денормализованной форме. Да, это может привести к дубликатам в выходных данных, но эти дубликаты будут устранены автоматически при использовании гулящая.Automapper чтобы автоматически отобразить результат этого запроса прямо на нашу карту объектов POCO.

USE [MyDatabase];
    SELECT tc.[ContactID] as ContactID
          ,tc.[ContactName] as ContactName
          ,tp.[PhoneId] AS TestPhones_PhoneId
          ,tp.[ContactId] AS TestPhones_ContactId
          ,tp.[Number] AS TestPhones_Number
          FROM TestContact tc
    INNER JOIN TestPhone tp ON tc.ContactId = tp.ContactId

C# код

const string sql = @"SELECT tc.[ContactID] as ContactID
          ,tc.[ContactName] as ContactName
          ,tp.[PhoneId] AS TestPhones_PhoneId
          ,tp.[ContactId] AS TestPhones_ContactId
          ,tp.[Number] AS TestPhones_Number
          FROM TestContact tc
    INNER JOIN TestPhone tp ON tc.ContactId = tp.ContactId";

string connectionString = // -- Insert SQL connection string here.

using (var conn = new SqlConnection(connectionString))
{
    conn.Open();    
    // Can set default database here with conn.ChangeDatabase(...)
    {
        // Step 1: Use Dapper to return the  flat result as a Dynamic.
        dynamic test = conn.Query<dynamic>(sql);

        // Step 2: Use Slapper.Automapper for mapping to the POCO Entities.
        // - IMPORTANT: Let Slapper.Automapper know how to do the mapping;
        //   let it know the primary key for each POCO.
        // - Must also use underscore notation ("_") to name parameters;
        //   see Slapper.Automapper docs.
        Slapper.AutoMapper.Configuration.AddIdentifiers(typeof(TestContact), new List<string> { "ContactID" });
        Slapper.AutoMapper.Configuration.AddIdentifiers(typeof(TestPhone), new List<string> { "PhoneID" });

        var testContact = (Slapper.AutoMapper.MapDynamic<TestContact>(test) as IEnumerable<TestContact>).ToList();      

        foreach (var c in testContact)
        {                               
            foreach (var p in c.TestPhones)
            {
                Console.Write("ContactName: {0}: Phone: {1}\n", c.ContactName, p.Number);   
            }
        }
    }
}

выход

Poco Entity Иерархия

глядя в Visual Studio, мы видим, что Slapper.Automapper правильно заполнил наши объекты POCO, т. е. у нас есть List<TestContact> и друг TestContact есть List<TestPhone>.

Примечания

как щеголь и гулящая.Automapper кэширует все внутренне для скорости. Если вы столкнулись с проблемами памяти (очень маловероятно), убедитесь, что вы иногда очищаете кэш для обоих из них.

убедитесь, что вы имя столбцы возвращаются, используя подчеркивание (_) обозначения дать гулящая.AutoMapper подсказывает, как отобразить результат в объекты POCO.

убедитесь, что вы даете Slapper.Ключи Automapper к первичному ключу для каждого объекта POCO (см. строки Slapper.AutoMapper.Configuration.AddIdentifiers). Вы также можете использовать Attributes на POCO для этого. Если вы пропустите этот шаг, то он может пойти не так (в теории), как Slapper.Automapper не знал бы, как правильно выполнить отображение.

обновление 2015-06-14

успешно применил этот метод к огромной производственной базе данных с более чем 40 нормализованными таблицами. Он отлично работал для отображения расширенного SQL-запроса с более чем 16 inner join и left join в правильную иерархию POCO (с 4 уровнями вложенности). Запросы слепо быстры, почти так же быстро, как ручное кодирование ADO.NET (обычно это было 52 миллисекунды для запроса и 50 миллисекунд для сопоставления из плоского результата в иерархию POCO). Это действительно ничего революционного, но он наверняка превосходит Entity Framework по скорости и простоте использования, особенно если все, что мы делаем, это запуск запросов.

обновление 2016-02-19

код работает безупречно в производстве в течение 9 месяцев. Последняя версия Slapper.Automapper имеет все изменения, которые я применил, чтобы исправить проблему, связанную с возвращением нулей в SQL-запросе.

обновление 2017-02-20

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

Slapper.Automapper также отлично подходит для сопоставления .csv-файл прямо в список POCOs. Читай .csv-файл в список IDictionary, а затем сопоставить его прямо в целевой список POCOs. Единственная хитрость заключается в том, что вы должны добавить свойство int Id {get; set}, и убедитесь, что он уникален для каждой строки (иначе automapper не сможет различать строки).

посмотреть: https://github.com/SlapperAutoMapper/Slapper.AutoMapper