Onde colocar o sql ao usar o dapper?

Question

Estou usando o dapper para um projeto mvc3 no trabalho e gosto dele.No entanto, como você deve colocar o aplicativo em camadas ao usar o dapper?Atualmente eu só tenho todo o meu sql inserido diretamente no controlador (tapa) mas estava pensando em fazer uma classe com strings estáticas..Então eu poderia fazer

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

Como você armazena seu sql ao usar o dapper?

Answer 1

eu diria coloque o sql onde você colocaria a consulta LINQ equivalente ou o sql para DataContext.ExecuteQuery.Quanto a onde é isso...bem, isso depende de você e depende de quanta separação você deseja.

No entanto, pessoalmente não vejo nenhum benefício em esconder o SQL em uma classe separada, longe do Query<T> ligar para você querer para vê-los no contexto para que você possa verificar facilmente os dados (e, de fato, os parâmetros).Você também pode construir a consulta (ainda parametrizada) in situ.Mas para uma consulta estática regular eu manteria o TSQL como um literal próximo ao código, a menos que eu tenha boa razão precisar dele abstraído, ou seja,

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

(observe também a alternativa método de extensão uso acima)

IMO, a chave acima é que é extremamente improvável que você reutilizaria essa consulta de qualquer outro lugar - a lógica seria colocada em um método, e esse método seria chamado de vários lugares.Portanto, o único outro motivo que você pode usar para ocultar a consulta atrás de um wrapper central é se você precisar oferecer suporte a diferentes provedores de banco de dados (com diferentes dialetos SQL).E isso é mais raro do que as pessoas imaginam.

Answer 2

Usar um arquivo de recurso é muito útil para nós.Criamos arquivos .sql em uma pasta chamada /Sql e os arrastamos para a seção 'Arquivos' de nosso objeto SqlResource.A seção 'Strings' do arquivo de recursos é realmente limpa e fácil para trechos menores de sql (por exemplo,funções que podemos estar consultando).

Então, nosso sql se parece com:

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

Isso mantém os repositórios realmente limpos.E há benefícios adicionais em ter todo o seu sql em um arquivo de recursos, pois você pode iterar sobre as entradas e potencialmente consultar o banco de dados com PARSEONLY para garantir que, se os objetos do banco de dados mudarem, suas consultas serão interrompidas (observe que isso ocorre principalmente, mas não 100% confiável).

Então, para concluir, para nós, os arquivos de recursos mantêm as coisas realmente limpas, mas, na opinião de Marc Gravell, eles não são para reutilização no código de produção... cada instrução sql deve ser usada apenas por um ponto em seu aplicativo.

Answer 3

Embora esta questão já esteja consideravelmente antiga, gostaria de sugerir ainda o armazenamento externo do SQL.O Visual Studio (pelo menos 2015+) possui destaque de sintaxe, bem como um pequeno depurador e gerenciador de conexões para arquivos *.sql.Os arquivos podem ainda ser marcados como Recurso incorporadose completamente contido no assembly, mas separado do seu código.Você passará a detestar ver SQL incolor incorporado em strings sem sintaxe verificada.

Adotei esse padrão em todos os meus projetos recentes e combinei com um ORM como Elegante, a interface entre C# e SQL se torna mínima.Tenho um projeto de código aberto que estende o Dapper disponível em GitHub que pode fornecer exemplos, bem como uma Pacote NuGet.Também inclui um bigode mecanismo de substituição de string inspirado, que é útil para modelar seus scripts para torná-los reutilizáveis ​​ou inserir condições de filtragem dinâmica.