Comment puis-je écrire une à plusieurs requêtes dans Dapper.Net?

Question

Comment puis-je écrire une à plusieurs requêtes dans Dapper.Net?

.net c# dapper

Question

J'ai écrit ce code pour projeter une relation un à plusieurs mais cela ne fonctionne pas:

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

Quelqu'un peut-il repérer l'erreur?

MODIFIER:

Ce sont mes entités:

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

MODIFIER:

Je change la requête pour:

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

et je me débarrasse des exceptions! Cependant, les employés ne sont pas du tout mappés. Je ne suis toujours pas sûr du problème avec IEnumerable<Employee> dans la première requête.

TCM

Réponse populaire

Je voulais rester aussi simple que possible, ma solution:

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

Je continue à faire un appel à la base de données, et alors que j'exécute maintenant 2 requêtes au lieu d'une, la deuxième requête utilise une jointure INNER au lieu d'une jointure LEFT moins optimale.

Davy

Voir plus sur Stack Overflow

Accepted Answer

Cet article explique comment interroger une base de données SQL hautement normalisée et mapper le résultat dans un ensemble d'objets C # POCO hautement imbriqués.

Ingrédients:

8 lignes de C #.
Certains SQL relativement simples qui utilisent des jointures.
Deux bibliothèques géniales.

L’idée qui m’a permis de résoudre ce problème est de séparer MicroORM du mapping the result back to the POCO Entities . Ainsi, nous utilisons deux bibliothèques distinctes:

Dapper comme le MicroORM.
Slapper.Automapper pour la cartographie.

Nous utilisons essentiellement Dapper pour interroger la base de données, puis Slapper.Automapper pour mapper le résultat directement dans nos POCO.

Avantages

La simplicité . C'est moins de 8 lignes de code. Je trouve cela beaucoup plus facile à comprendre, à déboguer et à modifier.
Moins de code . Slapper.Automapper doit gérer tout ce que vous lui envoyez, même si nous avons un POCO imbriqué complexe (c’est-à-dire que POCO contient la List<MyClass1> qui contient à son tour la List<MySubClass2> , etc.).
La vitesse . Ces deux bibliothèques disposent d’une quantité extraordinaire d’optimisations et de mise en cache qui leur permettent de fonctionner presque aussi vite que les requêtes ADO.NET réglées manuellement.
Séparation des préoccupations . Nous pouvons changer le MicroORM pour un autre, et le mappage fonctionne toujours, et vice-versa.
La flexibilité . Slapper.Automapper gère les hiérarchies imbriquées de manière arbitraire. Il ne se limite pas à quelques niveaux d'imbrication. Nous pouvons facilement apporter des modifications rapides et tout fonctionnera toujours.
Débogage . Nous pouvons d’abord constater que la requête SQL fonctionne correctement, puis nous pouvons vérifier que le résultat de la requête SQL est correctement mappé aux entités POCO cibles.
Facilité de développement en SQL . Je trouve que la création de requêtes aplaties avec des inner joins pour renvoyer des résultats plats est beaucoup plus facile que la création de plusieurs instructions de sélection, avec la broderie côté client.
Requêtes optimisées en SQL . Dans une base de données hautement normalisée, la création d'une requête simple permet au moteur SQL d'appliquer des optimisations avancées à l'ensemble, ce qui ne serait normalement pas possible si de nombreuses petites requêtes individuelles étaient construites et exécutées.
Confiance . Dapper est l’arrière de StackOverflow et, bien, Randy Burden est un peu une superstar. Ai-je besoin d'en dire plus?
Vitesse de développement. J'ai pu faire des requêtes extrêmement complexes, avec de nombreux niveaux d'imbrication, et le temps de développement était assez bas.
Moins de bugs. Je l'ai écrit une fois, cela a juste fonctionné, et cette technique aide maintenant à alimenter une entreprise FTSE. Il y avait tellement peu de code qu'il n'y avait pas de comportement inattendu.

Désavantages

Echelle supérieure à 1 000 000 de lignes retournées. Fonctionne bien lorsque vous renvoyez moins de 100 000 lignes. Cependant, si nous ramenons> 1.000.000 lignes, afin de réduire le trafic entre nous et le serveur SQL, il ne faut pas l' aplatir à l' aide de inner join (qui ramène les doublons), nous devrions plutôt utiliser plusieurs select des déclarations et point tout retour ensemble du côté client (voir les autres réponses sur cette page).
Cette technique est orientée requête . Je n'ai pas utilisé cette technique pour écrire dans la base de données, mais je suis sûr que Dapper est plus que capable de le faire avec davantage de travail supplémentaire, car StackOverflow lui-même utilise Dapper comme couche d'accès aux données (DAL).

Test de performance

Dans mes tests, Slapper.Automapper a ajouté une légère surcharge aux résultats renvoyés par Dapper, ce qui signifie qu’il était toujours 10 fois plus rapide que Entity Framework, et que la combinaison est encore bien foutue de la vitesse maximale théorique dont SQL + C # est capable .

Dans la plupart des cas pratiques, la majeure partie de la surcharge serait liée à une requête SQL non optimale, et non à un mappage des résultats du côté C #.

Résultats des tests de performance

Nombre total d'itérations: 1000

Dapper by itself - Dapper by itself : 1,889 millisecondes par requête, en utilisant 3 lines of code to return the dynamic .
Dapper + Slapper.Automapper : 2,463 millisecondes par requête, à l'aide de 3 lines of code for the query + mapping from dynamic to POCO Entities supplémentaires 3 lines of code for the query + mapping from dynamic to POCO Entities .

Exemple travaillé

Dans cet exemple, nous avons une liste de Contacts et chaque Contact peut avoir un ou plusieurs phone numbers .