c# - ¿Dónde poner sql al usar dapper?

asp.net-mvc-3 n-tier

Question

Estoy usando dapper para un proyecto mvc3 en el trabajo, y me gusta. Sin embargo, ¿cómo se supone que debes colocar la aplicación en capas cuando usas dapper? Actualmente solo tengo todos mis sql rellenos directamente en el controlador ( bofetada ) pero estaba pensando en hacer una clase con cadenas estáticas .. Así que podría hacer

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

¿Cómo almacenas tu sql cuando usas dapper?

Answer 1

Aunque esta pregunta ahora tiene una antigüedad considerable, me gustaría sugerir más el almacenamiento externo de SQL. Visual Studio (al menos 2015+) tiene resaltado de sintaxis, así como un pequeño depurador y administrador de conexión para archivos * .sql. Además, los archivos pueden marcarse como recursos incrustados y estar completamente contenidos dentro del conjunto, pero separados de su código. Crecerás hasta odiar el hecho de ver un SQL incoloro incrustado en cadenas no verificadas por sintaxis.

He adoptado este patrón en todos mis proyectos recientes, y combinado con un ORM como Dapper , la interfaz entre C # y SQL se vuelve muy mínima. Tengo un proyecto de código abierto que extiende Dapper disponible en GitHub que puede proporcionar ejemplos, así como un paquete NuGet . También incluye un motor de reemplazo de cadenas inspirado en el bigote , que es útil para crear plantillas de sus scripts para que sean reutilizables, o para insertar condiciones de filtrado dinámico.

Answer 2

Usar un archivo de recursos es realmente útil para nosotros. Creamos archivos .sql en una carpeta llamada / Sql y los arrastramos a la sección ''Archivos'' de nuestro objeto SqlResource. La sección ''Cadenas'' del archivo de recursos es realmente limpia y fácil para fragmentos más pequeños de sql (por ejemplo, funciones que podemos estar consultando).

Por lo tanto, nuestro sql se parece a:

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

Esto mantiene los repositorios realmente limpios. Y hay ventajas adicionales de tener todo su sql en un archivo de recursos en el que puede iterar sobre las entradas y potencialmente consultar la base de datos con PARSEONLY para asegurarse de que si los objetos de la base de datos cambian sus consultas se interrumpirían (tenga en cuenta que esto es principalmente pero no 100% confiable).

Entonces, para concluir, para nosotros, los archivos de recursos mantienen las cosas realmente limpias, pero para el punto de Marc Gravell no son reutilizables dentro del código de producción ... cada declaración de SQL solo debe ser utilizada por un punto en su aplicación.

Answer 3

Yo diría que coloque el sql donde debería haber colocado la consulta LINQ equivalente, o el sql para DataContext.ExecuteQuery . En cuanto a dónde está ... bueno, eso depende de usted y depende de cuánta separación desee.

Sin embargo, personalmente no veo ningún beneficio al ocultar el SQL en una clase separada de la llamada de Query<T> : desea verlos en contexto para que pueda verificar fácilmente los datos (y, de hecho, los parámetros). También puede estar construyendo la consulta (aún parametrizada) in situ. Pero para una consulta estática regular, mantendría el TSQL como un literal cerca del código, a menos que tenga una buena razón para necesitar un resumen, es decir

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

(Tenga en cuenta también el uso del método de extensión alternativa en el anterior)

En mi opinión, la clave de lo anterior es que es extremadamente improbable que alguna vez reutilice esa consulta desde cualquier otro lugar : la lógica se colocaría en un método y ese método se llamaría desde varios lugares. Por lo tanto, la única otra razón que podría usar para ocultar la consulta detrás de un contenedor central es si necesita admitir diferentes proveedores de bases de datos (con diferentes dialectos de SQL). Y eso es más raro que la gente.