¿Cómo escribo una a muchas consultas en Dapper.Net?

Question

¿Cómo escribo una a muchas consultas en Dapper.Net?

.net c# dapper

Pregunta

He escrito este código para proyectar una relación de uno a muchos, pero no está funcionando:

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 están mapeados en absoluto. Todavía no estoy seguro de qué problema tenía con IEnumerable<Employee> en la primera consulta.

TCM

Respuesta popular

Quería mantenerlo lo más simple posible, mi solución:

public List<ForumMessage> GetForumMessagesByParentId(int parentId)
{
    var sql = @"
    select d.id_data as Id, d.cd_group As GroupId, d.cd_user as UserId, d.tx_login As Login, 
        d.tx_title As Title, d.tx_message As [Message], d.tx_signature As [Signature], d.nm_views As Views, d.nm_replies As Replies, 
        d.dt_created As CreatedDate, d.dt_lastreply As LastReplyDate, d.dt_edited As EditedDate, d.tx_key As [Key]
    from 
        t_data d
    where d.cd_data = @DataId order by id_data asc;

    select d.id_data As DataId, di.id_data_image As DataImageId, di.cd_image As ImageId, i.fl_local As IsLocal
    from 
        t_data d
        inner join T_data_image di on d.id_data = di.cd_data
        inner join T_image i on di.cd_image = i.id_image 
    where d.id_data = @DataId and di.fl_deleted = 0 order by d.id_data asc;";

    var mapper = _conn.QueryMultiple(sql, new { DataId = parentId });
    var messages = mapper.Read<ForumMessage>().ToDictionary(k => k.Id, v => v);
    var images = mapper.Read<ForumMessageImage>().ToList();

    foreach(var imageGroup in images.GroupBy(g => g.DataId))
    {
        messages[imageGroup.Key].Images = imageGroup.ToList();
    }

    return messages.Values.ToList();
}

Todavía hago una llamada a la base de datos, y mientras ahora ejecuto 2 consultas en lugar de una, la segunda consulta usa una combinación INNER en lugar de una combinación LEFT menos óptima.

Davy

Ver más en Stack Overflow

Accepted Answer

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

Ingredientes:

8 líneas de C #.
Algunos SQL razonablemente simples que usan algunas combinaciones.
Dos bibliotecas impresionantes.

La información que me permitió resolver este problema es separar el MicroORM de la mapping the result back to the POCO Entities . Por lo tanto, utilizamos dos bibliotecas separadas:

Dapper como el microORM.
Slapper.Automapper para el mapeo.

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

Ventajas

La simplicidad Sus menos de 8 líneas de código. Encuentro esto mucho más fácil de entender, depurar y cambiar.
Menos código . Un par de líneas de código es todo lo que Slapper.Automapper necesita para manejar cualquier cosa que le lance, incluso si tenemos un POCO anidado complejo (es decir, POCO contiene la List<MyClass1> que a su vez contiene la List<MySubClass2> , etc.).
La velocidad Ambas bibliotecas tienen una extraordinaria cantidad de optimización y almacenamiento en caché para hacer que se ejecuten casi tan rápido como las consultas ADO.NET ajustadas a mano.
Separación de inquietudes . Podemos cambiar el MicroORM por otro 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. Fácilmente podemos hacer cambios rápidos, y todo seguirá funcionando.
Depuración Primero podemos ver que la consulta SQL está funcionando correctamente, luego podemos verificar que el resultado de la consulta SQL se asigne correctamente a las Entidades POCO de destino.
Facilidad de desarrollo en SQL . Encuentro que crear consultas planas con inner joins para devolver resultados planos es mucho más fácil que crear múltiples declaraciones de selección, con puntadas 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 extremo posterior de StackOverflow y, bueno, Randy Burden es un poco 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 bichos. 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 había comportamiento inesperado.

Desventajas

Escalado más allá de 1,000,000 de filas devueltas. Funciona bien cuando se devuelven <100,000 filas. Sin embargo, si estamos recuperando> 1,000,000 de filas, con el fin de reducir el tráfico entre nosotros y el servidor SQL, no deberíamos aplanarlo utilizando inner join (lo que trae duplicados), deberíamos usar múltiples declaraciones de select y volver a unir todo. juntos en el lado del cliente (ver las otras respuestas en esta página).
Esta técnica está orientada a la consulta . 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 un poco más de trabajo extra, ya que StackOverflow utiliza 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 aún 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 estaría en una consulta de SQL menos que óptima, y no con un mapeo 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, utilizando 3 lines of code for the query + mapping from dynamic to POCO Entities adicionales 3 lines of code for the query + mapping from dynamic to POCO Entities .

Ejemplo trabajado

En este ejemplo, tenemos una lista de Contacts y cada Contact puede tener uno o más phone numbers .