DEV Community: Bruno Freschi

DataAccess: ADO.net

Bruno Freschi — Fri, 10 Apr 2026 11:31:20 +0000

Controle total e performance máxima

Se você usa .NET, precisa entender o ADO.NET. Ele é a base de tudo — inclusive do Dapper e do Entity Framework.

O que é?

ADO.NET é o conjunto de APIs nativas do .NET para acessar banco de dados diretamente. Sem abstrações pesadas. Sem mágica.

👉 Resultado: máxima performance e controle absoluto.

Quando faz sentido usar?

Use ADO.NET quando:

Performance é crítica (ETL, alto volume, baixa latência)
Você precisa de controle fino sobre SQL e transações
Quer evitar dependências externas

Evite quando:

Precisa de produtividade rápida (CRUDs simples)
Não quer escrever mapeamento manual

Como funciona (essencial)

Os 3 principais componentes:

SqlConnection → abre conexão
SqlCommand → executa SQL
SqlDataReader → lê dados (streaming, rápido)

Exemplo direto:

using var connection = new SqlConnection(connectionString);
var command = new SqlCommand("SELECT Id, Nome FROM Clientes", connection);

connection.Open();

using var reader = command.ExecuteReader();
while (reader.Read())
{
    var id = reader.GetInt32(0);
    var nome = reader.GetString(1);
}

Sem ORM. Sem mapeamento automático. Só você e o banco.

Segurança básica (obrigatório)

Nunca faça isso:

$"SELECT * FROM Clientes WHERE Email = '{email}'"

Use parâmetros:

command.Parameters.AddWithValue("@Email", email);

👉 Evita SQL Injection e melhora cache de execução.

Performance: por que é tão rápido?

Sem reflexão
Sem geração de SQL
Leitura em streaming (DataReader)
Controle total de conexões

ETL? Aqui ele brilha

Para cargas massivas no SQL Server:

using var bulkCopy = new SqlBulkCopy(connection);
bulkCopy.DestinationTableName = "Clientes";
bulkCopy.WriteToServer(reader);

👉 Ordens de magnitude mais rápido que INSERT em loop

Comparação rápida

	ADO.NET	Dapper	EF
Performance	🔥 Máxima	Alta	Média
Controle SQL	Total	Total	Parcial
Facilidade	Baixa	Média	Alta

Regra prática

Quer controle e performance → ADO.NET
Quer equilíbrio → Dapper
Quer produtividade → EF

Insight final

Dominar ADO.NET muda seu nível como backend .NET.

Você passa a entender o que realmente acontece entre sua aplicação e o banco.

E isso impacta diretamente em performance, custo e escalabilidade.

Link para o repo.

BrunoSFreschi / DataAccess.Benchmark

DataAccess Benchmark é um laboratório de engenharia de software criado para analisar, o custo das diferentes abordagens de acesso a dados no ecossistema .NET.

DataAccess Benchmark

Ao estudar performance, não estamos apenas medindo tempo de execução Estamos observando a história da engenharia de software se manifestando em código.

Este repositório foi criado para demonstrar, de forma prática, a evolução das abordagens de acesso a dados no ecossistema .NET, comparando:

ADO.NET (baixo nível, controle total)
Dapper (micro-ORM, performance com praticidade)
Entity Framework Core (ORM completo, foco em produtividade)

Tudo medido com precisão usando BenchmarkDotNet, a ferramenta padrão para benchmarks profissionais em .NET.

Este projeto não é apenas um teste Ele é um laboratório para entender como a engenharia de software evoluiu ao longo dos anos.

A História do Acesso a Dados no .NET

Assim como a POO surgiu da Crise do Software, as diferentes formas de acessar banco de dados surgiram de um problema recorrente:

Como acessar dados com segurança, performance e manutenibilidade ao mesmo tempo?

Durante a evolução do .NET, três…

View on GitHub

POO Além do Código #4: Polimorfismo (A Versatilidade)

Bruno Freschi — Tue, 31 Mar 2026 20:39:36 +0000

"A capacidade de tratar diferentes objetos através de uma interface comum."

📜 A Perspectiva Histórica

Nos primeiros sistemas orientados a objetos, era comum usar grandes blocos de if e switch para decidir o comportamento do programa.
Cada novo tipo exigia alterar o código existente, aumentando o risco de bugs e tornando o sistema difícil de manter.

O Polimorfismo surgiu como solução para esse problema.
Em vez de perguntar "que tipo é esse?", o código passa a dizer "faça isso", e cada objeto sabe como responder.

Esse conceito permitiu criar sistemas extensíveis, onde novos comportamentos podem ser adicionados sem modificar o código antigo.
Essa ideia é a base do princípio Open/Closed Principle (Aberto para extensão, fechado para modificação).

💡 O Conceito

Polimorfismo significa múltiplas formas.

Objetos diferentes podem ser tratados da mesma maneira, desde que compartilhem um contrato comum (interface ou classe base).

O código trabalha com o tipo abstrato
Cada objeto executa sua própria implementação
O comportamento muda sem mudar o código que chama

O foco do Polimorfismo é a EXTENSIBILIDADE e a FLEXIBILIDADE.

🛠️ No Mundo Real (Agnóstico)

Imagine um Controle Remoto Universal:

O controle tem um botão "Ligar"
A TV liga de um jeito
O Ar-condicionado liga de outro
O Videogame liga de outro

O controle não precisa saber como cada aparelho funciona.
Ele só chama o mesmo comando.

Cada aparelho responde do seu próprio jeito.

Isso é Polimorfismo.

💻 Implementação em C# (Nossa Ferramenta)

Sem polimorfismo, o código fica rígido e cheio de condições.

Com polimorfismo, usamos interfaces ou classes base.

// Contrato comum
public interface IMetodoPagamento
{
    void Pagar(decimal valor);
}

// Implementação 1
public class PagamentoCartao : IMetodoPagamento
{
    public void Pagar(decimal valor)
    {
        Console.WriteLine($"Pagando {valor} no cartão");
    }
}

// Implementação 2
public class PagamentoPix : IMetodoPagamento
{
    public void Pagar(decimal valor)
    {
        Console.WriteLine($"Pagando {valor} via PIX");
    }
}

// Implementação 3
public class PagamentoBoleto : IMetodoPagamento
{
    public void Pagar(decimal valor)
    {
        Console.WriteLine($"Pagando {valor} com boleto");
    }
}

// Classe que usa polimorfismo
public class ProcessadorPagamento
{
    public void Processar(IMetodoPagamento metodo, decimal valor)
    {
        metodo.Pagar(valor);
    }
}

Uso:

var processador = new ProcessadorPagamento();

IMetodoPagamento p1 = new PagamentoCartao();
IMetodoPagamento p2 = new PagamentoPix();
IMetodoPagamento p3 = new PagamentoBoleto();

processador.Processar(p1, 100);
processador.Processar(p2, 200);
processador.Processar(p3, 300);

Se amanhã surgir um novo tipo:

public class PagamentoCripto : IMetodoPagamento

Nada precisa ser alterado no código existente.

Isso é Polimorfismo.

🎯 Desafio de Mentalidade

Ao olhar para o código nesta pasta, pergunte-se:

Estou usando muitos if ou switch para decidir comportamento?
Posso substituir isso por interface ou classe base?
Meu código aceita novos tipos sem precisar ser modificado?
Estou programando para a implementação ou para a abstração?
Se eu adicionar um novo comportamento, preciso mexer no código antigo?

POO Além do Código #3: Herança e Composição (A Estrutura)

Bruno Freschi — Wed, 25 Mar 2026 23:35:56 +0000

"A herança diz o que um objeto É, a composição diz o que um objeto TEM."

📜 A Perspectiva Histórica

No início da POO, a Herança era vista como a "bala de prata" para o reuso de código. Se você precisasse de um "Carro" e já tivesse um "Veículo", bastava herdar. Com o tempo, os sistemas ficaram rígidos e frágeis (o "problema da banana e do gorila": você queria a banana, mas vinha o gorila e a floresta inteira junto). A Composição surgiu como uma alternativa mais flexível para montar sistemas como peças de LEGO.

💡 O Conceito

Herança (É um): Cria uma hierarquia rígida. É útil quando existe uma relação natural e imutável de especialização.
Composição (Tem um): Cria uma relação de dependência. Você monta o objeto injetando outros objetos dentro dele. É a base para o código modular e testável.

O segredo do bom arquiteto é: "Prefira composição em vez de herança" (Design Patterns GoF).

🛠️ No Mundo Real (Agnóstico)

Imagine um Smartphone:

Herança: O Smartphone É UM Dispositivo Eletrônico. Ele herda características básicas como "voltagem" e "botão power".
Composição: O Smartphone TEM UMA Câmera, TEM UM GPS e TEM UMA Bateria.
Por que compor? Se a tecnologia da câmera mudar de "Digital" para "Lidar", você só troca a peça. Se você usasse herança para tudo, teria que mudar a árvore genealógica inteira do telefone.

💻 Implementação em C# (Nossa Ferramenta)

Veja como a Composição evita que as classes fiquem "inchadas" e presas a uma hierarquia.

// --- HERANÇA ---
public class Veiculo {
    public string Marca { get; set; }
    public void Ligar() => Console.WriteLine("Ligado!");
}

public class Carro : Veiculo { // Carro É UM Veículo
    public int Portas { get; set; }
}

// --- COMPOSIÇÃO ---
public interface IMotor {
    void Iniciar();
}

public class MotorGasolina : IMotor {
    public void Iniciar() => Console.WriteLine("Vrum vrum (Gasolina)");
}

public class CarroModerno : Veiculo {
    // O carro TEM UM motor (Injetado via composição)
    private readonly IMotor _motor;

    public CarroModerno(IMotor motor) {
        _motor = motor;
    }

    public void Acelerar() => _motor.Iniciar();
}

🎯 Desafio de Mentalidade

Ao olhar para o código nesta pasta, pergunte-se:

Eu usei Herança apenas para economizar de digitar código? (Se sim, cuidado: isso é um erro comum).
Se eu precisar trocar um comportamento desta classe no futuro, eu consigo fazer isso sem alterar a classe pai?
"Um Quadrado é um Retângulo?" (O famoso Círculo de Liskov). Se a resposta for "mais ou menos", use Composição.

POO Além do Código #2: Encapsulamento (A Caixa Preta)

Bruno Freschi — Wed, 18 Mar 2026 12:12:30 +0000

"Um objeto deve ser responsável por manter seu próprio estado e proteger sua integridade."

📜 A Perspectiva Histórica

Nos primórdios da programação, as variáveis eram globais. Qualquer parte do código podia alterar o valor de qualquer outra parte. O resultado? O "Efeito Colateral": você consertava um erro no login e, inexplicavelmente, quebrava o cálculo do frete. O Encapsulamento surgiu para criar fronteiras, garantindo que o que acontece dentro de um objeto, fica dentro do objeto.

💡 O Conceito

Encapsular é a arte de esconder a complexidade interna e expor apenas o necessário.
Pense no objeto como uma célula: ela tem uma membrana que protege o núcleo. Você não altera o DNA da célula cutucando-a com o dedo; você interage com os receptores da membrana.

O foco do Encapsulamento é a PROTEÇÃO e a VALIDAÇÃO dos dados.

🛠️ O Encapsulamento no Mundo Real (Agnóstico)

Imagine um Relógio de Pulso:

Interface Pública: O visor e o botão de ajuste de hora.
Encapsulamento (Privado): As engrenagens, a bateria e o cristal de quartzo.
Por que isso é bom? Se você pudesse tocar diretamente nas engrenagens para mudar a hora, acabaria entortando uma peça. O relógio te obriga a usar o botão, que garante que as engrenagens girem da forma correta.

💻 Implementação em C# (Nossa Ferramenta)

Aqui, usamos Modificadores de Acesso (private, public, protected) e Properties (get e set) para controlar o acesso aos dados.

public class ContaBancaria 
{
    // O saldo é privado: ninguém de fora pode simplesmente digitar um novo valor.
    private decimal _saldo;

    public decimal Saldo 
    {
        get { return _saldo; } // Apenas leitura externa
    }

    // O método é a única "porta" de entrada segura.
    public void Depositar(decimal valor) 
    {
        if (valor > 0) 
        {
            _saldo += valor;
            Console.WriteLine($"Depósito de {valor} realizado com sucesso.");
        }
    }

    public void Sacar(decimal valor) 
    {
        if (valor <= _saldo) 
        {
            _saldo -= valor;
        }
        else 
        {
            Console.WriteLine("Saldo insuficiente.");
        }
    }
}

🎯 Desafio de Mentalidade

Ao olhar para o código nesta pasta, pergunte-se:

Meus campos (fields) são privados?
Existe alguma forma de deixar o objeto em um "estado inválido" (ex: saldo negativo, idade -5)? Se sim, falta encapsulamento.
O mundo externo realmente precisa saber como esse cálculo é feito, ou apenas o resultado final dele?

POO Além do Código #1: Abstração (O Arquiteto de Soluções)

Bruno Freschi — Thu, 12 Mar 2026 19:35:57 +0000

Você já sentiu que seu código está virando um "emaranhado" de funções, mesmo usando classes? Muitas vezes, o problema não é a linguagem ou o framework, mas a falta de um conceito fundamental que separa os digitadores de código dos arquitetos de software: a Abstração.

Neste primeiro artigo da série sobre os pilares da POO, vamos descer um nível e entender por que a abstração é a alma de sistemas escaláveis.

🧐 O que é Abstração, afinal?

Abstrair não é "esconder código". Abstrair é a arte de ignorar o que não importa em um determinado contexto.

Imagine um objeto Carro. Dependendo do sistema que você está construindo, a abstração dele muda completamente:

Contexto	O que importa (Abstração)	O que é irrelevante
GPS / Logística	Latitude, Longitude, Velocidade	Cor do estofado, Tipo de óleo
Oficina Mecânica	Histórico de revisões, Peças, KM	Destino da viagem atual
E-commerce	Preço, Modelo, Ano, Estoque	Pressão dos pneus

Regra de Ouro: Foque no O QUE o objeto faz, e não no COMO ele faz.

🎮 O Exemplo do Controle Remoto

Pense na interface de um controle remoto. Você tem botões para Ligar(), MudarCanal() e AjustarVolume().

Para você, não importa se a TV recebe o sinal via Infravermelho, Bluetooth ou Wi-Fi. A abstração (os botões) permanece a mesma, enquanto a implementação (a eletrônica interna) pode mudar completamente sem que você precise aprender a usar o controle de novo.

💻 Abstração na Prática (C#)

Quando trazemos isso para o código, estamos definindo contratos de comportamento. Veja este exemplo focado no domínio de pagamentos:

// Definimos o "Contrato": Todo meio de pagamento DEVE ser processado.
// O COMO (Pix, Cartão, Boleto) não nos interessa neste nível.

public abstract class MeioDePagamento
{
    public decimal Valor { get; set; }

    // O arquiteto define o comportamento, mas deixa a execução para o futuro.
    public abstract void Processar();
}

Estou aplicando neste repo. alguns conceitos

BrunoSFreschi/Blueprint-OOP

Por que isso é poderoso?

Se amanhã surgir o "CryptoPay", você não precisa alterar a lógica principal do seu sistema. Você apenas cria uma nova classe que herda de MeioDePagamento e implementa o método Processar(). O restante do software continua conversando com a abstração.

🚨 O Erro Comum: O "Procedural Disfarçado"

No ecossistema .NET, é muito comum cairmos na armadilha das classes "Anêmicas" acompanhadas de gerenciadores:

UserService
UserHelper
UserManager

Se o seu objeto User só tem propriedades (get/set) e toda a lógica está em um "Helper", você não está fazendo Orientação a Objetos. Você está fazendo Programação Procedural dentro de classes.

A abstração real acontece quando o objeto possui comportamento e responsabilidades claras dentro do seu contexto.

🧠 Checkpoint Mental

Antes de criar sua próxima classe, faça estas quatro perguntas:

🏦 Domínio: Esta classe representa um objeto real do meu negócio?
🔍 Contexto: Estou colocando detalhes que não pertencem a este cenário?
⚙️ Tecnologia: Se eu trocar o banco de dados ou a UI, essa ideia ainda faz sentido?
🎭 Comportamento: Estou modelando ações ou apenas guardando dados (balde de variáveis)?

🛤️ Próximos Passos

A abstração é o alicerce. Sem ela, os outros pilares perdem o sentido. No próximo post, vamos falar sobre Encapsulamento: como proteger essa abstração e garantir que ninguém "mexa nos fios" por trás do controle remoto.

E você? Já pegou algum sistema onde a falta de abstração tornou uma mudança simples em um pesadelo de refatoração? Deixe nos comentários!

#dotnet #csharp #poo #architecture #programming

Seu código é Orientado a Objetos

Bruno Freschi — Thu, 05 Mar 2026 17:19:48 +0000

🚀 O seu código é Orientado a Objetos ou apenas um "Procedural Disfarçado"?

Vamos tocar na ferida: o que mais existe por aí é o famoso "Código de Estimação". Aquele código empacotado em classes, cheio de getters e setters para todo lado, mas sem um pingo de inteligência ou comportamento real.

Se o código procedural resolve o problema e entrega o software, por que se dar ao trabalho de modelar objetos? A resposta não está na execução, mas na sustentabilidade.

Por que a OO (bem feita) salva o seu projeto?

Controle da Complexidade (O fim do Espaguete): No procedural, os dados são passivos e as funções globais. Conforme o sistema cresce, mexer em um ponto quebra cinco outros lugares imprevisíveis. A OO propõe o Encapsulamento: cada objeto é uma "caixa preta" que cuida da própria vida.
Flexibilidade sem Cirurgia (Polimorfismo): Precisa adicionar um novo meio de pagamento (ex: Cripto)? Em vez de espalhar if/else por todo o sistema, você apenas cria um novo objeto que sabe "Processar". Você adiciona funções sem tocar no que já está funcionando.

🏛️ Os 4 Pilares na Prática

Pilar	O que resolve na vida real?
Abstração	Esconde a complexidade. Você dirige o carro sem precisar entender a explosão interna do motor.
Encapsulamento	Protege os dados. Ninguém altera o "Saldo" sem passar pelas regras de negócio.
Herança	Compartilha características comuns, evitando redundância (mas cuidado para não virar um pesadelo!).
Polimorfismo	Permite que diferentes objetos respondam à mesma mensagem de formas específicas.

💡 O Veredito

Usamos Orientação a Objetos para que o código seja legível para humanos, e não apenas compreensível para máquinas. O custo de manutenção de um software é, em média, 80% do seu ciclo de vida.

A OO bem aplicada é um investimento para que o desenvolvedor do futuro (que pode ser você daqui a seis meses) não queira deletar tudo e começar do zero.

E aí, o seu código atual passaria em um teste de pureza de OO? 🧐

#programação #softwareDevelopment #cleanCode #OOP #devLife #brazilianDevs

First post

Bruno Freschi — Thu, 31 Oct 2024 16:12:19 +0000

Este é um post de teste. A intenção aqui é simplesmente validar a funcionalidade da plataforma, testar configurações de exibição e verificar se tudo está funcionando corretamente. Este post de teste, teste, teste, servirá para garantir que o conteúdo seja exibido de maneira esperada para quem acessa, além de nos ajudar a identificar possíveis ajustes de formatação e estrutura.

Ao utilizar este post de teste, conseguimos visualizar se o layout responde conforme o planejado. Esse tipo de teste é fundamental para garantir que não haja problemas quando um conteúdo real for publicado. Vale lembrar que posts como este são temporários e servem exclusivamente para fins de verificação e avaliação de desempenho, aparência e usabilidade. Assim, qualquer pessoa que esteja visualizando isso pode ter certeza de que se trata de um conteúdo provisório.

Esses testes são importantes também para observar a fluidez da leitura, identificar erros de configuração e, eventualmente, ajustar o conteúdo. Este post de teste é também uma oportunidade para analisar como o sistema lida com conteúdos um pouco mais longos, especialmente quando precisamos simular algo próximo de um post finalizado.