Utilisation de Dapper pour remplir des objets à partir d'une vue T-SQL

c# dapper multi-mapping

Question

J'essaie d'utiliser Dapper pour mon accès aux données (dans ASP.NET MVC3 FWIW). J'ai une vue T-SQL (dans SQL Server) qui ressemble à ceci:

SELECT s.*, c.CompanyId AS BreakPoint c.Name AS CompanyName
FROM tblStaff AS s
INNER JOIN tblCompanies AS c ON c.CompanyId = s.CompanyId

Tellement simple Essentiellement une liste de personnel ayant chacun une seule entreprise.

Le problème que j'ai est que j'essaie de mapper la sortie de cette requête sur mes POCO, mais parce que chaque champ de la vue doit être unique (c'est-à-dire CompanyName au lieu de Name qui existe déjà dans tblStaff) ne fonctionne pas.

Voici le code:

var sql = @"select * from qryStaff";
var people = _db.Query<Person, Company, Person>(sql, (person, company) => {person.Company = company; return person;}, splitOn: "BreakPoint");

Un conseil pour résoudre ce casse-tête? Je suis ouvert à changer ma façon de voir, car je ne sais pas comment progresser.

Réponse populaire

Vous devez explicitement lister tous les champs renvoyés par votre vue (pas d'astérisques!) Et lorsque les noms de champs ne sont pas uniques, utilisez des alias pour dédupliquer. En exemple:

SELECT 
    s.CompanyName as CompanyName1, 
    s.BreakPoint as BreakPoint1,
    ...
    c.CompanyId AS BreakPoint,
    c.Name AS CompanyName
FROM tblStaff AS s
INNER JOIN tblCompanies AS c ON c.CompanyId = s.CompanyId

Les champs répertoriés et les alias que vous pourriez utiliser dépendent bien entendu entièrement de votre code. En règle générale, vous ajustez les alias de votre requête pour qu'ils correspondent aux noms de propriété du POCO.

En outre, en règle générale, il est préférable d'éviter les caractères génériques dans les requêtes SQL, car de tels problèmes sont introduits. Voici un article décent sur les meilleures pratiques en matière de requêtes SQL.

Extrait:

L'utilisation de noms explicites de colonnes dans vos instructions SELECT dans votre code présente de nombreux avantages. Premièrement, SQL Server renvoie uniquement les données dont votre application a besoin, et non pas un ensemble de données supplémentaires que votre application n’utilisera pas. En ne renvoyant que les données dont vous avez besoin, vous optimisez la quantité de travail que SQL Server doit effectuer pour rassembler toutes les colonnes d'informations requises. De plus, en n'utilisant pas la nomenclature astérisque (*), vous minimisez également la quantité de trafic réseau (nombre d'octets) nécessaire pour envoyer les données associées à votre instruction SELECT à votre application.

De plus, en nommant explicitement vos colonnes, vous protégez votre application des échecs potentiels liés à certaines modifications du schéma de base de données susceptibles de se produire pour toute table référencée dans votre instruction SELECT. Si vous utilisiez la nomenclature astérisque (*) et que quelqu'un devait ajouter une nouvelle colonne à une table, votre application commencerait à recevoir des données pour cette colonne supplémentaire, même sans modifier le code de votre application. Si votre application s'attend à ce qu'un nombre spécifique de colonnes soit renvoyée, elle échouera dès que quelqu'un ajoutera une colonne supplémentaire à l'une de vos tables référencées. Par conséquent, en nommant explicitement les colonnes dans votre instruction SELECT, votre application obtiendra toujours le même nombre de colonnes renvoyées, même si quelqu'un ajoute une nouvelle colonne à l'une des tables référencées dans votre instruction SELECT.



Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi