Tutorial de Conexão SQL em C#: Dapper + Banco de Dados SQL Server Explicado

Configuração e Limpeza do Projeto

Tim começa revisando a estrutura da solução e confirmando as alterações feitas na lição anterior. Em Program.cs, ele explica que adicionou código para conectar tanto a SQL Server quanto a bancos de dados de arquivo de texto, e mudou o formulário de inicialização para o formulário "Create Prize" para que ele possa testar a conexão do banco de dados imediatamente.

Ele então reorganiza a estrutura do projeto criando duas pastas:

• Modelos

• DataAccess

Ele observa que isso não afeta a funcionalidade do código-fonte, mas ajuda na organização. Quando você retorna a um projeto mais tarde, uma estrutura limpa e nomes consistentes tornam muito mais fácil de manter e expandir.

Por que Dapper?

Tim explica que irá usar o Dapper como o ORM (Mapeador Objeto-Relacional) para conexões SQL. Dapper fica entre comandos SQL brutos e ORMs de nível superior como o Entity Framework.

Tim prefere o Dapper porque ele é:

• Quase tão rápido quanto ADO.NET puro

• Mais simples que o Entity Framework

• Evita complexidade desnecessária e códigos boilerplate pesados

Ele menciona que o Entity Framework pode ser mais lento e mais pesado, especialmente para aplicações pequenas. Para o projeto dele, o Dapper oferece o equilíbrio certo entre desempenho e simplicidade.

Instalando o Dapper

Tim demonstra a instalação do Dapper através do Gerenciador de Pacotes NuGet no Visual Studio. Após a instalação, o Dapper aparece nas referências do projeto, e o código de conexão SQL torna-se limpo e legível.

Adicionando a String de Conexão

Para usar o Dapper, você precisa de uma string de conexão. Tim a adiciona ao arquivo app.config do projeto da UI, não do projeto da biblioteca, porque a biblioteca é um DLL e não tem sua própria configuração.

A string de conexão inclui:

• Fonte de Dados (nome do servidor ou nome de domínio da máquina)

• Catálogo Inicial (nome do banco de dados)

• Segurança Integrada (Autenticação do Windows)

• Tempo de Expiração da Conexão

• ID de Usuário e Senha (se não estiver usando a Autenticação do Windows)

No exemplo de Tim, ele usa conexão confiável, ou seja, autenticação do Windows:

Data Source=SQL2016;Initial Catalog=Tournaments;Integrated Security=True;

Ele enfatiza que isso evita o armazenamento de credenciais de usuário do SQL Server no arquivo.

GlobalConfig: Obtendo a String de Conexão

Para recuperar a string de conexão, Tim adiciona um método no GlobalConfig:

public static string GetConnectionString(string name)
{
return ConfigurationManager.ConnectionStrings[name].ConnectionString;
}

Este método extrai a string de conexão do arquivo de configuração e a retorna. Tim também adiciona a referência necessária ao System.Configuration.

Criando a Conexão SQL

Tim remove o código placeholder e cria uma SqlConnection real usando:

using (IDbConnection connection = new SqlConnection(
GlobalConfig.GetConnectionString("tournaments")))
{
// lógica SQL aqui
}

Ele usa uma interface IDbConnection para que ele possa trocar os tipos de banco de dados (SQL ou arquivo de texto) sem mudar o código principal.

O bloco using é importante porque garante que a conexão seja fechada automaticamente quando o código sair do bloco. Isso evita conexões abertas que podem esgotar o pool de conexões ou causar erros no servidor de banco de dados.

Criando o Procedimento Armazenado

Em vez de escrever SQL bruto dentro do C#, Tim usa um procedimento armazenado. Isso mantém a lógica SQL no banco de dados e reduz riscos como injeção SQL.

Ele cria um procedimento armazenado chamado:

dbo.SP_Prizes_Insert

Este procedimento aceita parâmetros que correspondem à tabela de prêmio:

• @PlaceNumber

• @PlaceName

• @PrizeAmount

• @PrizePercentage

• @ID (saída)

O parâmetro de saída retorna o ID recém-gerado usando:

SELECT @ID = SCOPE_IDENTITY()

Isso garante que o novo ID do registro seja retornado para o aplicativo C#.

Parâmetros Dinâmicos no Dapper

De volta ao C#, Tim usa os DynamicParameters do Dapper para enviar parâmetros ao procedimento armazenado:

var p = new DynamicParameters();
p.Add("@PlaceNumber", model.PlaceNumber);
p.Add("@PlaceName", model.PlaceName);
p.Add("@PrizeAmount", model.PrizeAmount);
p.Add("@PrizePercentage", model.PrizePercentage);
p.Add("@ID", 0, dbType: DbType.Int32, direction: ParameterDirection.Output);

O ID é marcado como Saída, e o Dapper lida com o mapeamento dos parâmetros.

Executando o Procedimento Armazenado

Ele executa o procedimento armazenado:

connection.Execute("dbo.SP_Prizes_Insert", p, commandType: CommandType.StoredProcedure);

Execute é usado porque ele realiza uma inserção e não retorna linhas como um comando SELECT.

Após a execução, o código recupera o ID:

model.ID = p.Get<int>("@ID");
return model;

Teste e Resultados

Tim executa o aplicativo, preenche o formulário, e clica em Create Prize. Os dados são inseridos no banco de dados SQL Server com sucesso. Ele testa ambos:

• Quantia do Prêmio

• Percentual do Prêmio

Ambos funcionam, provando que a conexão com o banco de dados e o procedimento armazenado funcionam corretamente.

Desafio de Design: Múltiplos Conectores de Dados (1:01:50)

Tim destaca um problema de design: usar conectores SQL e de arquivo de texto simultaneamente causa IDs inconsistentes.

Então ele altera o design para que apenas um conector seja executado por vez. Ele adiciona um enum:

DatabaseType
{
SQL,
TextFile
}

Isso garante que o aplicativo sempre use um tipo de banco de dados consistente, e previne misturar os dados do banco de diferentes fontes.

Conclusão

A Lição 10 de Tim Corey mostra uma abordagem do mundo real para conectar um aplicativo C# ao SQL Server usando o Dapper. Ele cobre:

• Adicionar uma string de conexão

• Usando SqlConnection

• Abrindo e fechando conexões com segurança

• Usando procedimentos armazenados

• Evitando injeção SQL

• Arquitetura adequada para múltiplas fontes de dados

Se você quer uma maneira limpa, rápida e manutenível de conectar C# a um banco de dados SQL Server, essa lição é um guia perfeito.