Как написать запрос "один ко многим" в Dapper.Net?

Question 1

Я написал этот код для проецирования отношения один ко многим, но он не работает:

using (var connection = new SqlConnection(connectionString))
{
   connection.Open();

   IEnumerable<Store> stores = connection.Query<Store, IEnumerable<Employee>, Store>
                        (@"Select Stores.Id as StoreId, Stores.Name, 
                                  Employees.Id as EmployeeId, Employees.FirstName,
                                  Employees.LastName, Employees.StoreId 
                           from Store Stores 
                           INNER JOIN Employee Employees ON Stores.Id = Employees.StoreId",
                        (a, s) => { a.Employees = s; return a; }, 
                        splitOn: "EmployeeId");

   foreach (var store in stores)
   {
       Console.WriteLine(store.Name);
   }
}

Кто-нибудь может заметить ошибку?

РЕДАКТИРОВАТЬ:

Это мои сущности:

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public double Price { get; set; }
    public IList<Store> Stores { get; set; }

    public Product()
    {
        Stores = new List<Store>();
    }
}

public class Store
{
    public int Id { get; set; }
    public string Name { get; set; }
    public IEnumerable<Product> Products { get; set; }
    public IEnumerable<Employee> Employees { get; set; }

    public Store()
    {
        Products = new List<Product>();
        Employees = new List<Employee>();
    }
}

РЕДАКТИРОВАТЬ:

Я меняю запрос на:

IEnumerable<Store> stores = connection.Query<Store, List<Employee>, Store>
        (@"Select Stores.Id as StoreId ,Stores.Name,Employees.Id as EmployeeId,
           Employees.FirstName,Employees.LastName,Employees.StoreId 
           from Store Stores INNER JOIN Employee Employees 
           ON Stores.Id = Employees.StoreId",
         (a, s) => { a.Employees = s; return a; }, splitOn: "EmployeeId");

и избавляюсь от исключений! Однако сотрудники вообще не отображаются. Я до сих пор не уверен, с чем возникла проблема IEnumerable<Employee>в первом запросе.

Question 2

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

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

8 строк C #.
Какой-то достаточно простой SQL, который использует некоторые объединения.
Две классные библиотеки.

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

Dapper как MicroORM.
Slapper.Automapper для отображения.

По сути, мы используем Dapper для запроса к базе данных, а затем используем Slapper.Automapper для отображения результата прямо в наши POCO.

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

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

Недостатки

Возвращено масштабирование за пределы 1 000 000 строк. Хорошо работает при возврате <100 000 строк. Однако, если мы возвращаем> 1000000 строк, чтобы уменьшить трафик между нами и SQL-сервером, мы не должны сглаживать его с помощью inner join(что возвращает дубликаты), вместо этого мы должны использовать несколько selectоператоров и объединить все вместе на на стороне клиента (см. другие ответы на этой странице).
Этот метод ориентирован на запросы . Я не использовал этот метод для записи в базу данных, но я уверен, что Dapper более чем способен сделать это с дополнительной работой, поскольку сам StackOverflow использует Dapper в качестве уровня доступа к данным (DAL).

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

В моих тестах Slapper.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.