DEV Community: Gustavo Cremonez

[Boost]

Gustavo Cremonez — Wed, 04 Jun 2025 16:36:06 +0000

Gustavo Cremonez

Jun 4 '25

Padrão Unit of Work: O Coordenador de Transações em Aplicações .NET

#webdev #programming #backend #beginners

Comments

4 min read

Padrão Unit of Work: O Coordenador de Transações em Aplicações .NET

Gustavo Cremonez — Wed, 04 Jun 2025 13:34:02 +0000

O Desafio da Gestão Transacional

Em sistemas corporativos, operações que envolvem múltiplas entidades - como registrar um pedido, debitar estoque e atualizar o histórico do cliente - precisam ser tratadas como uma única unidade lógica. O padrão Unit of Work surge como solução para esse desafio, atuando como um orquestrador de transações que garante a integridade dos dados mesmo em cenários complexos.

Neste artigo, exploraremos os fundamentos desse padrão, seu papel na arquitetura de software moderna e como ele se relaciona com outros conceitos como o Repository Pattern e Domain-Driven Design.

A Essência do Padrão Unit of Work

O Unit of Work (UoW) é muito mais do que uma simples abstração técnica - é um padrão comportamental que organiza como as operações de persistência são gerenciadas em sistemas complexos. Para entender sua essência, vamos decompô-lo em princípios fundamentais:

Atomicidade como Filosofia Central
O UoW materializa o princípio ACID de atomicidade no nível de aplicação:

Agrupa operações (inserts, updates, deletes) em uma única unidade lógica;
Garante tudo ou nada: Todas as operações são confirmadas ou nenhuma é persistida;
Exemplo prático: Em um sistema bancário, transferências entre contas só são completas se débito e crédito forem ambos bem-sucedidos;

Rastreamento Inteligente de Estado
Um UoW eficiente atua como "memória transacional":

Mantém registro de todas as entidades modificadas durante uma operação;
Conhece o estado original e as alterações pendentes;

Coordenação de Recursos Múltiplos
Em arquiteturas modernas, o UoW evoluiu para lidar com:

Múltiplos bancos de dados (SQL + NoSQL)
Sistemas distribuídos (microserviços com seus próprios repositórios)
Fontes heterogêneas (banco de dados + filas + APIs externas)

Controle de Vida Útil (Lifetime Management)
O UoW gerencia o ciclo de vida das operações:

Início: Quando a unidade de trabalho é instanciada
Registro: Operações são adicionadas ao contexto
Validação: Verificação de consistência antes do commit
Persistência: Escrita no(s) armazenamento(s)
Finalização: Liberação de recursos (sucesso ou falha)

Elementos Constituintes Fundamentais

Um Unit of Work bem projetado possui três componentes essenciais:

Contexto de Operações

Função: Contêiner que agrega todas as mudanças pendentes
Implementação: Normalmente um objeto que rastreia:
- Novas entidades para inserir
- Entidades modificadas para atualizar
- Entidades marcadas para exclusão

Mecanismo de Commit

Responsabilidade: Executar todas as operações pendentes de forma atômica
Complexidade: Varia de simples (um banco) a complexo (sagas distribuídas)
Garantias: Deve assegurar idempotência em caso de retentativas

Estratégia de Rollback

Necessidade: Restaurar o estado consistente em caso de falha
Abordagens comuns:
- Compensação (operações inversas)
- Mecanismos ORM (change tracking reversal)
- Transações distribuídas (two-phase commit)

Unit of Work em Harmonia com Outros Padrões

A Sinfonia com o Repository Pattern O Unit of Work e o Repository são parceiros naturais em arquiteturas robustas. Enquanto o Repository atua como uma coleção especializada para entidades específicas (como um bibliotecário que conhece cada prateleira), o Unit of Work é o gerente que coordena todas as operações do sistema. Juntos, formam uma dupla poderosa:

Repositórios fornecem acesso granular a entidades individuais:

customerRepository.GetById(123);
orderRepository.Add(newOrder);

Unit of Work orquestra múltiplos repositórios em uma transação unificada:

using (var uow = unitOfWorkFactory.Create()) 
{
    uow.CustomerRepository.Update(customer);
    uow.OrderRepository.Add(order);
    uow.Commit(); // Atomicidade garantida
}

Essa simbiose permite que operações complexas (ex: transferir saldo entre contas) mantenham consistência sem expor detalhes de persistência ao domínio.

2. Integração com Domain-Driven Design (DDD)
No DDD, o Unit of Work torna-se o guardião da integridade do agregado:

Preservação de Invariantes: Garante que regras de negócio complexas (ex: "limite de crédito não pode ser negativo") sejam validadas antes do commit.
Alinhamento com Bounded Contexts: Cada contexto delimitado pode ter sua própria implementação de UoW, respeitando fronteiras estratégicas:

Suporte a Domain Events: Coordena a publicação de eventos após o commit bem-sucedido:

uow.Commit(); // Persiste dados
eventDispatcher.Publish(events); // Dispara eventos

Conclusão: O Maestro das Transações Complexas

O Unit of Work transcende sua função técnica para tornar-se um pilar arquitetural essencial em sistemas onde integridade é não negociável. Sua verdadeira força revela-se quando combinado com padrões como Repository e DDD:

Para Repository: É o maestro que transforma solos individuais (operações em repositórios) em uma sinfonia coesa (transações complexas).

Para DDD: É o guardião que protege as invariantes do domínio e materializa intenções de negócio em operações atômicas.

Em cenários modernos - de microsserviços a arquiteturas orientadas a eventos - o Unit of Work evoluiu para orquestrar não apenas bancos de dados, mas serviços distribuídos, filas de mensagens e APIs externas. Sua implementação requer equilíbrio entre rigor transacional e flexibilidade, mas quando bem executada, torna-se a base invisível que sustenta sistemas resilientes e confiáveis.

Padrão Repository: A Abstração que Transformou o Acesso a Dados em Aplicações .NET

Gustavo Cremonez — Sat, 24 May 2025 10:55:02 +0000

No desenvolvimento de software moderno, uma das decisões mais críticas é como estruturar o acesso a dados. O padrão Repository emergiu como uma das soluções mais elegantes para este desafio, criando uma camada de abstração entre sua lógica de negócios e os mecanismos de armazenamento. Neste artigo, vamos explorar:

O que é o padrão Repository e por que ele foi criado;
Como ele se diferencia de outras abordagens;
Seu relacionamento com outros padrões como Unit of Work;
Quando usar (e quando não usar) esta abordagem;

Nos primórdios do desenvolvimento de aplicações, o acesso a dados era frequentemente implementado de forma direta e desestruturada. Os desenvolvedores escreviam queries SQL diretamente nos controllers, resultando em:

Alto acoplamento: A lógica de negócios ficava intimamente ligada ao esquema do banco de dados;
Dificuldade de teste: Era complexo isolar componentes para testes unitários;
Falta de padronização: Diferentes partes do sistema acessavam dados de formas distintas;
Complexidade na manutenção: Mudanças no esquema do banco exigiam alterações em múltiplos pontos do código;

// Exemplo do problema: acesso direto a dados no controller
public class ProdutoController : Controller
{
    public IActionResult Listar()
    {
        using (var connection = new SqlConnection(connectionString))
        {
            var produtos = connection.Query<Product>("SELECT * FROM Products");
            return View(produtos);
        }
    }
}

O padrão Repository foi formalizado como parte do Domain-Driven Design (DDD) por Eric Evans em seu livro seminal de 2004. A ideia central era:

"Fornecer uma abstração de coleção em memória para objetos de domínio, escondendo os detalhes de como e onde esses objetos são persistidos."

Esta abordagem trouxe vários benefícios:

Separação de preocupações: A lógica de negócios não precisa saber como os dados são armazenados;
Testabilidade: Podemos facilmente mockar o Repository para testes unitários;
Flexibilidade: A fonte de dados pode ser trocada sem afetar o domínio;
Consistência: Todas as operações de dados seguem o mesmo padrão;

O padrão Repository ocupa um espaço único no ecossistema de acesso a dados, diferenciando-se significativamente de outras abordagens comuns. Para entender seu valor, vamos contrastá-lo com três alternativas principais:

Repository vs Acesso Direto ao Banco
Antes da popularização dos ORMs, era comum ver aplicações acessando bancos de dados diretamente:

// Abordagem tradicional sem Repository
public List<Cliente> GetClientesPremium()
{
    using (var connection = new SqlConnection(connectionString))
    {
        return connection.Query<Cliente>(
            "SELECT * FROM Clientes WHERE Premium = 1").ToList();
    }
}

Problemas:

SQL hardcoded em toda a aplicação;
Difícil manutenção quando o esquema muda;
Quase impossível de testar unitariamente;

O Repository resolve isso encapsulando todas as operações de dados em uma única camada.

Repository vs ORM Direto (Entity Framework Core)

Muitos desenvolvedores questionam: "Por que usar Repository se o EF Core já é uma abstração?"

// Uso direto do DbContext (sem Repository)
public class ProdutoService
{
    private readonly AppDbContext _context;

    public ProdutoService(AppDbContext context)
    {
        _context = context;
    }

    public List<Produto> GetProdutosEmEstoque()
    {
        return _context.Produtos.Where(p => p.Estoque > 0).ToList();
    }
}

Diferenças chave:

Nível de abstração: Repository esconde completamente o ORM usado;
Flexibilidade: Facilita trocar EF por Dapper ou outro ORM;
Contrato explícito: Interface do Repository define claramente as operações disponíveis;

Repository vs Micro ORMs (Dapper)

Enquanto Dapper é excelente para performance, ele não oferece:

Abstração de operações CRUD;
Gerenciamento de estado;
Fácil substituição por outra tecnologia;

O Repository adiciona essa camada organizacional.

O Repository raramente trabalha sozinho. Ele faz parte de um ecossistema de padrões:

Repository + Unit of Work
A combinação mais clássica e poderosa:

Vantagens:

Controle transacional centralizado;
Coordenação entre múltiplos repositories;
Padronização de operações de persistência;

Repository + Specification Pattern
Para queries complexas:

public interface ISpecification<T>
{
    Expression<Func<T, bool>> Criteria { get; }
    List<Expression<Func<T, object>>> Includes { get; }
}

public class ProdutosEmEstoqueSpec : ISpecification<Produto>
{
    public Expression<Func<Produto, bool>> Criteria => p => p.Estoque > 0;
    public List<Expression<Func<Produto, object>>> Includes => new() { p => p.Categoria };
}

Repository + CQRS

Em arquiteturas mais avançadas:
[Command Side] → [Repository] → [Banco de Dados]
[Query Side] → [Queries Diretas] → [Cache/Read Model]

Casos Ideais para Repository

Para ajudar a decidir quando o padrão Repository é a escolha certa, veja este fluxograma de decisão:

O padrão Repository, quando aplicado corretamente, oferece:

✔ Separação clara de responsabilidades;
✔ Flexibilidade tecnológica;
✔ Testabilidade aprimorada;
✔ Manutenibilidade a longo prazo;

Porém, como qualquer padrão, não é uma solução universal. A chave está em:

Avaliar as necessidades reais do projeto;
Implementar de forma moderada;
Manter o foco no domínio;

Em projetos .NET modernos, uma abordagem equilibrada pode ser:

Usar Repository para operações de escrita/comando;
Usar abordagens mais diretas (Dapper, queries) para leitura;

Referências Úteis
📌 Repository Pattern (Microsoft Docs)

📌 Repository Pattern (Martin Fowler)

E você? Como tem utilizado o padrão Repository em seus projetos? Compartilhe suas experiências nos comentários!

O que são Middlewares em APIs .NET?

Gustavo Cremonez — Mon, 19 May 2025 16:55:27 +0000

Se você já trabalhou com APIs em .NET, provavelmente já ouviu falar sobre Middlewares. Mas afinal, o que são e por que são tão importantes?

Neste artigo, vamos explorar o conceito de Middlewares no contexto de APIs .NET, entender como eles funcionam e ver exemplos práticos de como utilizá-los.

O que são Middlewares?

Middlewares são componentes que formam o pipeline de processamento de requisições em uma aplicação .NET. Eles são responsáveis por lidar com solicitações HTTP (requests) e respostas HTTP (responses), permitindo executar lógicas antes e depois que uma requisição chegue ao seu endpoint final.

Pense em um middleware como uma "camada" que a requisição passa antes de chegar ao seu destino (e também na volta, quando a resposta é enviada ao cliente).

Analogia do Middleware

Imagine um restaurante:

Você faz um pedido (request).
Antes de chegar ao cozinheiro (sua API Controller), o pedido passa pelo garçom, que verifica se está completo (middleware de validação).
Depois de pronto, o prato (response) pode passar por outro garçom que adiciona temperos extras (middleware de transformação).

Cada middleware tem uma função específica e pode interromper o fluxo se necessário.

Como os Middlewares Funcionam no .NET?

No .NET, o pipeline de middlewares é configurado no arquivo Program.cs, usando o método Use, Run ou Map.

Exemplo Básico de Middleware

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// Middleware 1: Logging
app.Use(async (context, next) =>
{
    Console.WriteLine($"Requisição recebida: {context.Request.Path}");
    await next(); // Chama o próximo middleware
});

// Middleware 2: Autorização
app.Use(async (context, next) =>
{
    if (!context.Request.Headers.ContainsKey("Authorization"))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Não autorizado");
        return; // Interrompe o pipeline
    }
    await next();
});

// Rota principal
app.MapGet("/", () => "Hello World!");

app.Run();

Neste exemplo:

O primeiro middleware registra o caminho da requisição.
O segundo middleware verifica se há um header de autorização. Se não houver, retorna 401 Unauthorized.

Se tudo estiver correto, a requisição chega ao endpoint principal (/).

Middlewares Comuns no .NET
O .NET já possui vários middlewares prontos para uso:

UseRouting() Define o roteamento da aplicação.
UseAuthentication() Habilita autenticação.
UseAuthorization() Habilita autorização.
UseCors() Configura políticas CORS.
UseStaticFiles() Permite servir arquivos estáticos (HTML, CSS, JS).

Exemplo com Middlewares Integrados

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/secure", () => "Rota segura!").RequireAuthorization();

app.Run();

A Ordem Importa!

No .NET, a sequência em que os middlewares são registrados no Program.cs define a ordem de execução. Isso é crucial, pois um middleware pode depender do processamento de outro. Por exemplo:

app.UseHttpsRedirection(); // 1º: Redireciona para HTTPS  
app.UseStaticFiles();      // 2º: Serve arquivos estáticos (CSS, JS)  
app.UseRouting();         // 3º: Define as rotas  
app.UseAuthentication();  // 4º: Autentica o usuário  
app.UseAuthorization();   // 5º: Verifica as permissões

Se você inverter UseRouting e UseAuthentication, a autenticação não funcionará, pois o roteamento ainda não terá identificado o endpoint a ser protegido.

Quando Criar um Middleware Personalizado?

Você pode criar um middleware personalizado quando:

Precisa validar algo em todas as requisições (ex: checar API Key).
Quer loggar todas as requisições/respostas.
Precisa transformar respostas (ex: adicionar headers customizados).

Um uso comum é centralizar o tratamento de exceções para evitar repetição de código:

Middleware de Tratamento de Erros:

app.UseExceptionHandler(errorApp =>  
{  
    errorApp.Run(async context =>  
    {  
        var error = context.Features.Get<IExceptionHandlerFeature>();  
        context.Response.StatusCode = 500;  
        await context.Response.WriteAsJsonAsync(new  
        {  
            Message = "Ocorreu um erro inesperado.",  
            Details = error?.Error.Message  
        });  
    });  
});

Impacto na Performance

Middlewares adicionam overhead ao pipeline. Para evitar gargalos:

Use middlewares leves (ex.: evite processamento bloqueante).
Registre apenas os necessários (em produção, desative logs detalhados).
Considere UseWhen para aplicar middlewares condicionalmente:

app.UseWhen(context => context.Request.Path.StartsWith("/api"), appBuilder =>  
{  
    appBuilder.UseMiddleware<ApiSpecificMiddleware>();  
});

Conclusão
Middlewares são peças fundamentais no desenvolvimento de APIs .NET, permitindo adicionar comportamentos personalizados ao pipeline de requisições. Eles podem ser usados para logging, autenticação, tratamento de erros e muito mais.

Dominar middlewares ajuda a criar aplicações mais modulares, seguras e eficientes.

Referências Úteis
Documentação Oficial: Middlewares no ASP.NET Core

E aí, já usou middlewares em seus projetos? Conte nos comentários! 🚀