Où mettre SQL lors de l'utilisation de Dapper?

asp.net-mvc-3 c# dapper n-tier

Question

J'utilise dapper pour un projet mvc3 au travail, et je l'aime bien. Cependant, comment êtes-vous censé superposer l'application lors de l'utilisation de dapper? Actuellement, je ne dispose que de tous mes fichiers SQL directement dans le contrôleur ( slap ), mais je pensais créer une classe avec des chaînes statiques.

var reports = Dapper.Query<Report>(conn, MySql.ReportsRunningQuery)

Comment stockez-vous votre SQL lors de l'utilisation de dapper?

Réponse acceptée

Je dirais mettre le sql où vous auriez mis la requête LINQ équivalente, ou le sql pour DataContext.ExecuteQuery . Pour ce qui est de savoir où c'est ... et bien, cela dépend de vous et de la séparation que vous voulez.

Cependant, personnellement, je ne vois aucun avantage à cacher le SQL dans une classe distincte de l'appel Query<T> - vous voulez les voir en contexte pour pouvoir facilement vérifier les données (et même les paramètres). Vous pouvez également construire la requête (toujours paramétrée) in situ. Mais pour une requête statique régulière, je garderais le TSQL comme un littéral près du code, sauf si j'ai de bonnes raisons de l'exiger, c'est-à-dire

var reports = conn.Query<Report>(@"
select x.blah, y.blah
from x (snip)
where x.ParentId = @parentId and y.Region = @region", new {parentId, region});

(notez également l'utilisation alternative de la méthode d'extension dans ce qui précède)

IMO, la clé dans ce qui précède est qu'il est extrêmement improbable que vous n'utilisiez jamais cette requête à partir d' un autre endroit - la logique serait plutôt intégrée à une méthode et cette méthode serait appelée à partir de plusieurs endroits. Donc, la seule autre raison pour laquelle vous pouvez masquer la requête derrière un wrapper central est si vous devez prendre en charge différents fournisseurs de bases de données (avec des dialectes SQL différents). Et c'est plus rare que ce que les gens font.


Réponse populaire

L'utilisation d'un fichier de ressources est vraiment utile pour nous. Nous créons des fichiers .sql dans un dossier call / Sql et les déposons dans la section 'Files' de notre objet SqlResource. La section 'Strings' du fichier de ressources est vraiment propre et facile à utiliser pour les petits fragments de SQL (par exemple les fonctions que nous pouvons interroger).

Donc, notre sql ressemble à:

var reports = conn.Query<Report>(SqlResource.Blahs_get, new {parentId, region});

Cela garde les dépôts vraiment propres. Et il y a des avantages supplémentaires à avoir tous vos fichiers SQL dans un fichier de ressources dans la mesure où vous pouvez parcourir les entrées et potentiellement interroger la base de données avec PARSEONLY pour vous assurer que si les objets db changent, vos requêtes 100% fiable).

Donc, pour conclure, pour nous, les fichiers de ressources gardent les choses vraiment propres, mais pour Marc Gravell, ils ne sont pas réutilisables dans le code de production ... chaque instruction sql ne doit être utilisée que par un point de votre application.




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