¿Cómo escribo una consulta de uno a muchos en Dapper.Net?

Question 1

Escribí este código para proyectar una relación de uno a muchos, pero no funciona:

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);
   }
}

¿Alguien puede detectar el error?

EDITAR:

Estas son mis entidades:

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>();
    }
}

EDITAR:

Cambio la consulta a:

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");

¡y me deshago de las excepciones! Sin embargo, los empleados no se asignan en absoluto. Todavía no estoy seguro de qué problema tuvo IEnumerable<Employee>en la primera consulta.

Question 2

Esta publicación muestra cómo consultar una base de datos SQL altamente normalizada y mapear el resultado en un conjunto de objetos C # POCO altamente anidados.

Ingredientes:

8 líneas de C #.
Algún SQL razonablemente simple que usa algunas combinaciones.
Dos fantásticas bibliotecas.

La idea que me permitió resolver este problema es separar el MicroORMde mapping the result back to the POCO Entities. Por lo tanto, usamos dos bibliotecas separadas:

Dapper como el MicroORM.
Slapper.Automapper para mapeo.

Esencialmente, usamos Dapper para consultar la base de datos, luego usamos Slapper.Automapper para mapear el resultado directamente en nuestros POCO.

Ventajas

Sencillez . Tiene menos de 8 líneas de código. Encuentro esto mucho más fácil de entender, depurar y cambiar.
Menos código . Unas pocas líneas de código son todo Slapper. Automapper necesita manejar cualquier cosa que le arrojes , incluso si tenemos un POCO anidado complejo (es decir, POCO contiene List<MyClass1>que a su vez contiene List<MySubClass2>, etc.).
Velocidad . Ambas bibliotecas tienen una cantidad extraordinaria de optimización y almacenamiento en caché para que se ejecuten casi tan rápido como las consultas ADO.NET ajustadas a mano.
Separación de preocupaciones . Podemos cambiar el MicroORM por uno diferente, y el mapeo aún funciona, y viceversa.
Flexibilidad . Slapper.Automapper maneja jerarquías anidadas arbitrariamente, no se limita a un par de niveles de anidación. Podemos hacer cambios rápidos fácilmente y todo seguirá funcionando.
Depuración . Primero podemos ver que la consulta SQL funciona correctamente, luego podemos verificar que el resultado de la consulta SQL esté correctamente mapeado a las Entidades POCO de destino.
Facilidad de desarrollo en SQL . Encuentro que crear consultas aplanadas inner joinspara devolver resultados planos es mucho más fácil que crear múltiples declaraciones de selección, con uniones en el lado del cliente.
Consultas optimizadas en SQL . En una base de datos altamente normalizada, la creación de una consulta plana permite que el motor SQL aplique optimizaciones avanzadas al conjunto, lo que normalmente no sería posible si se construyeran y ejecutaran muchas consultas individuales pequeñas.
Confianza . Dapper es el back-end de StackOverflow y, bueno, Randy Burden es una superestrella. ¿Necesito decir algo más?
Velocidad de desarrollo. Pude hacer algunas consultas extraordinariamente complejas, con muchos niveles de anidamiento, y el tiempo de desarrollo fue bastante bajo.
Menos errores. Lo escribí una vez, simplemente funcionó, y esta técnica ahora está ayudando a impulsar una empresa FTSE. Había tan poco código que no hubo ningún comportamiento inesperado.

Desventajas

Se devolvió la escala más allá de 1.000.000 de filas. Funciona bien cuando se devuelven <100.000 filas. Sin embargo, si recuperamos> 1,000,000 de filas, para reducir el tráfico entre nosotros y el servidor SQL, no debemos aplanarlo usando inner join(que trae duplicados), en su lugar debemos usar múltiples selectdeclaraciones y unir todo de nuevo en el lado del cliente (vea las otras respuestas en esta página).
Esta técnica está orientada a consultas . No he usado esta técnica para escribir en la base de datos, pero estoy seguro de que Dapper es más que capaz de hacer esto con más trabajo adicional, ya que StackOverflow usa Dapper como su capa de acceso a datos (DAL).

Pruebas de rendimiento

En mis pruebas, Slapper.Automapper agregó una pequeña sobrecarga a los resultados devueltos por Dapper, lo que significaba que todavía era 10 veces más rápido que Entity Framework, y la combinación todavía está bastante cerca de la velocidad máxima teórica que SQL + C # es capaz de hacer .

En la mayoría de los casos prácticos, la mayor parte de la sobrecarga se produciría en una consulta SQL menos que óptima y no con una asignación de los resultados en el lado C #.

Resultados de las pruebas de rendimiento

Número total de iteraciones: 1000

Dapper by itself: 1.889 milisegundos por consulta, usando 3 lines of code to return the dynamic.
Dapper + Slapper.Automapper: 2.463 milisegundos por consulta, usando un adicional 3 lines of code for the query + mapping from dynamic to POCO Entities.

Ejemplo resuelto

En este ejemplo, tenemos una lista de Contactsy cada uno Contactpuede tener uno o más phone numbers.