Wo soll SQL abgelegt werden, wenn Dapper verwendet wird?

Question

Ich verwende Dapper für ein MVC3-Projekt bei der Arbeit und es gefällt mir.Doch wie soll man die Anwendung schichten, wenn man Dapper verwendet?Derzeit habe ich nur alle meine SQL-Dateien direkt im Controller (schlagen), aber ich habe darüber nachgedacht, eine Klasse mit statischen Zeichenfolgen zu erstellen.Das könnte ich tun

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

Wie speichern Sie Ihr SQL, wenn Sie Dapper verwenden?

Answer 1

ich würde sagen Platzieren Sie die SQL dort, wo Sie die entsprechende LINQ-Abfrage platziert hätten, oder die SQL für DataContext.ExecuteQuery.Wo das ist...Nun, das liegt an Ihnen und hängt davon ab, wie viel Trennung Sie wünschen.

Persönlich sehe ich jedoch keinen Vorteil darin, die SQL in einer separaten Klasse außerhalb der zu verstecken Query<T> ruf an - du wollen um sie im Kontext zu sehen, damit Sie die Daten (und tatsächlich die Parameter) leicht überprüfen können.Möglicherweise erstellen Sie die Abfrage (noch parametrisiert) auch vor Ort.Aber für eine normale statische Abfrage würde ich das TSQL als Literal in der Nähe des Codes behalten, es sei denn, ich habe es getan guter Grund es abstrahieren zu müssen, d.h.

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

(Beachten Sie auch die Alternative Erweiterungsmethode Verwendung oben)

Meiner Meinung nach ist der Schlüssel zum oben Gesagten, dass es so ist äußerst unwahrscheinlich dass Sie diese Abfrage jemals wiederverwenden würden Jeder andere Ort - Die Logik würde stattdessen in eine Methode eingefügt und diese Methode von mehreren Stellen aus aufgerufen.Der einzige andere Grund, warum Sie die Abfrage möglicherweise hinter einem zentralen Wrapper verstecken, besteht darin, dass Sie verschiedene Datenbankanbieter (mit unterschiedlichen SQL-Dialekten) unterstützen müssen.Und das kommt seltener vor, als man denkt.

Answer 2

Die Verwendung einer Ressourcendatei ist für uns wirklich nützlich.Wir erstellen SQL-Dateien in einem Ordner Call / SQL und ziehen Sie sie in den Abschnitt "Dateien" unseres SQLRESURCE-Objekts.Der Abschnitt "Strings" der Ressourcendatei ist wirklich sauber und für kleinere Snippets von SQL (z. B. Funktionen, die wir möglicherweise abfragen können).

Also sieht unsere SQL aus wie: generasacodicetagpre.

Dies hält die Repositories echt sauber.Und es gibt zusätzliche Vorteile, um alle Ihre SQL in einer Ressourcendatei in einer Ressourcendatei zu haben, in der Sie die Einträge untersuchen können, und möglicherweise die DB mit Parseonly perfrieren, um sicherzustellen, dass, wenn DB-Objekte Ihre Abfragen ändern würden (beachten Sie, dass dies meistens jedoch ist, nicht100% zuverlässig).

Zum Schluss, für US-Ressourcen-Dateien die Dinge, um die Dinge echt sauber zu halten, aber auf den Punkt von Marc Gravell sind sie nicht zur Wiederverwendbarkeit innerhalb des Produktionscodes ... Jede SQL-Anweisung sollte nur von einem Punkt in Ihrer Anwendung verwendet werden.

Answer 3

Obwohl diese Frage nun erheblich gealtert ist, möchte ich den externen Speicher von SQL weiter vorschlagen. Visual Studio (mindestens 2015+) verfügt über Syntax-Hervorhebung sowie einen kleinen Debugger- und Verbindungsmanager für * .sql-Dateien. Die Dateien können ferner als eingebettete Ressource S markiert und vollständig in der Baugruppe enthalten, sondern von Ihrem Code getrennt. Sie werden wachsen, um die farblose SQL zu sehen, die in nicht-syntaxverifizierten Saiten eingebettet ist.

Ich habe dieses Muster auf all meine letzten Projekte angenommen, und kombiniert mit einem Orm wie dapper wird die Schnittstelle zwischen C # und SQL sehr minimal. Ich habe ein Open-Source-Projekt, das sich auf github anbietet A Nuget-Paket . Es enthält auch einen inspirierten String-Ersatzmotor inspiriert, der für das Vorzenieren Ihrer Skripts nützlich ist, um sie wiederverwendbar oder dynamische Filterbedingungen einzulegen.