¿Dónde poner sql al usar dapper?

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

Pregunta

Estoy usando dapper para un proyecto de mvc3 en el trabajo, y me gusta. Sin embargo, ¿cómo se supone que debes aplicar capas a la aplicación cuando usas dapper? Actualmente tengo todo mi sql rellenado 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 almacena su sql cuando usa dapper?

Respuesta aceptada

Yo diría que coloque el sql donde habría puesto la consulta LINQ equivalente, o el sql para DataContext.ExecuteQuery . En cuanto a dónde está ... bueno, depende de ti y depende de la cantidad de separación que desees.

Sin embargo, personalmente no veo beneficio alguno al ocultar el SQL en una clase aparte de la llamada Query<T> : desea verlos en contexto para que pueda verificar fácilmente los datos (y de hecho, los parámetros). También podría estar construyendo la consulta (aún parametrizada) in situ. Pero para una consulta estática regular, mantendría el TSQL como literal cerca del código, a menos que tenga una buena razón para necesitarlo abstraído, 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 alternativo en el anterior)

OMI, la clave en lo anterior es que es extremadamente improbable que alguna vez vuelva a utilizar esa consulta desde cualquier otro lugar ; la lógica se colocaría en un método, y ese método se invocaría desde múltiples lugares. Entonces, 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 SQL). Y eso es más raro de lo que la gente se imagina.


Respuesta popular

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 'Strings' del archivo de recursos está realmente limpia y es fácil para fragmentos más pequeños de sql (por ejemplo, funciones que podemos estar consultando).

Entonces, nuestro sql se ve así:

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

Esto mantiene los repositorios realmente limpios. Y hay beneficios adicionales de tener todos sus sql en un archivo de recursos en el que puede iterar sobre las entradas y potencialmente consultar el db con PARSEONLY para asegurarse de que si los objetos db cambian sus consultas se romperían (tenga en cuenta que esto es mayormente pero no 100% confiable).

Por lo tanto, para concluir, para nosotros los archivos de recursos mantienen las cosas realmente limpias, pero para Marc Gravell, no son para ser reutilizados dentro del código de producción ... cada sentencia sql solo debe ser utilizada por un punto en su aplicación.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow