Porque usar

Por que usar o Repository Pattern

Por que usar o Repository Pattern

O Repository Pattern existe para resolver um problema específico e recorrente em sistemas de software:

O acoplamento do domínio aos detalhes de persistência.

Ele cria uma fronteira clara entre o que o sistema faz e como os dados são armazenados, permitindo que regras de negócio evoluam sem depender diretamente de banco de dados, ORM ou tecnologia específica.

Isolamento do domínio

O principal motivo para usar o Repository Pattern é proteger o domínio.

Sem um repositório, regras de negócio tendem a depender diretamente de:

• SQL;

• consultas específicas de ORM;

• estruturas físicas de banco;

• detalhes de armazenamento.

Com o padrão, o domínio trabalha apenas com contratos. Ele expressa intenções, não mecanismos.

Isso preserva o domínio como o centro do sistema.

Redução de acoplamento tecnológico

Repositórios reduzem o impacto de mudanças tecnológicas.

Ao isolar a persistência:

• trocar o banco deixa de ser traumático;

• mudar de ORM não exige reescrita do domínio;

• decisões de infraestrutura ficam localizadas.

A persistência passa a ser um detalhe substituível, não uma dependência estrutural.

Clareza de intenção

Um bom repositório não expõe CRUD genérico.

Ele oferece operações que fazem sentido para o domínio, como:

• buscar um agregado;

• salvar uma entidade consistente;

• recuperar dados conforme regras reais do negócio.

Isso torna o código mais legível, expressivo e alinhado com a linguagem do domínio.

Testabilidade

Ao depender de abstrações, o domínio se torna facilmente testável.

Repositórios:

• podem ser simulados (mocks ou fakes);

• eliminam dependência de banco em testes de regra;

• permitem testes rápidos e determinísticos.

Isso melhora a qualidade do código e reduz o custo de manutenção.

Separação de responsabilidades

O Repository Pattern reforça uma separação clássica e saudável:

• o domínio decide;

• o repositório acessa;

• a infraestrutura executa.

Cada parte tem uma responsabilidade clara, sem sobreposição.

Evolução do sistema

Sistemas mudam. Persistência, mais ainda.

O Repository Pattern permite:

• evoluir o domínio com menos impacto;

• adaptar a persistência a novas demandas;

• incorporar caches, filas ou serviços externos sem quebrar regras de negócio.

Essa flexibilidade é essencial em sistemas que não são descartáveis.

Quando ele realmente faz sentido

O padrão é especialmente útil quando:

• existe domínio relevante;

• há regras de negócio claras;

• a persistência não é trivial;

• o sistema precisa evoluir ao longo do tempo.

Quando evitar

Não é uma solução universal.

O Repository Pattern pode ser desnecessário quando:

• a aplicação é puramente CRUD;

• não existe domínio real;

• a persistência é simples e estável;

• a sobrecarga arquitetural não se justifica.

Conclusão

O Repository Pattern não existe para “embelezar” arquitetura.

Ele existe para proteger o domínio, reduzir acoplamento e permitir evolução segura do sistema.

Usado com critério, continua sendo um dos fundamentos mais sólidos da arquitetura de software — não por moda, mas por necessidade real.

Por se tratar de um sistema simples será utilizado a nomenclatura Models para criar o diretório, pois representa dados para um contexto específico.

Model vs Entity

Model vs Entity

Em projetos .NET (e arquiteturas em geral), os termos Model e Entity são frequentemente usados como sinônimos, mas eles não são a mesma coisa conceitualmente. A diferença não é obrigatória por linguagem, e sim arquitetural.

Entender quando usar um ou outro ajuda a manter o sistema claro e bem estruturado.

O que é uma Entity

Uma Entity é um conceito do domínio.

Ela representa algo que possui identidade própria e ciclo de vida dentro do sistema. Duas entidades podem ter os mesmos valores e ainda assim serem diferentes, desde que possuam identidades distintas.

Características de uma Entity:

• possui identidade (Id)

• representa um conceito do negócio

• pode conter regras de negócio

• existe independentemente da persistência

• faz parte do core domain

Exemplo típico de Entity:

• Product

• Order

• Customer

Em arquiteturas orientadas a domínio, Entity é semântica, não técnica.

O que é um Model

O termo Model é mais genérico e contextual.

Ele representa uma estrutura de dados para um propósito específico, que pode ou não ter relação direta com o domínio.

Um Model pode ser:

• um DTO

• um ViewModel

• um input de API

• um objeto de retorno

• uma estrutura de persistência

• uma projeção de dados

Características comuns de Models:

• não possuem identidade de domínio

• geralmente são anêmicos

• existem para transporte ou adaptação de dados

• variam conforme a camada (API, UI, Infra, etc.)

Por que a confusão é comum

Em muitos frameworks (incluindo ASP.NET), o termo Model é usado de forma ampla:

• Model Binding

• ViewModel

• Request Model

• Response Model

Isso faz com que toda classe de dados acabe sendo chamada de “model”, mesmo quando semanticamente ela é uma entity.

ASP.NET MVC, Web API, Razor Pages, Blazor… todos vêm com pastas como:

• Models

• Controllers

• Views

Aí nasce o mito: “ah, isso aqui é Model porque é um projeto MVC”.

Errado.

Essas pastas são organização de framework, não definição conceitual.

Exemplo prático

Num mesmo projeto ASP.NET Web API:

• Product (Entity) Representa o produto do negócio. Tem identidade. Tem regra.

• CreateProductRequest (Model) Representa o que chega via HTTP. Pode mudar amanhã sem afetar o domínio.

• ProductResponse (Model) Representa o que sai da API. Pode omitir dados, formatar, adaptar.

Tudo no mesmo tipo de projeto.

Diferença conceitual

Aspecto	Entity	Model
Identidade	Essencial	Geralmente inexistente
Pertence ao	Domínio	Camada específica
Regras de negócio	Pode conter	Normalmente não contém
Ciclo de vida	Relevante	Transitório
Papel arquitetural	Conceito do negócio	Estrutura de dados

Por que usar Entities

Use Entities quando:

• existe domínio real

• há regras de negócio associadas

• a identidade importa

• o objeto representa algo persistente

• o sistema precisa evoluir com segurança

Entities são a base de arquiteturas orientadas a domínio.

Por que usar Models

Use Models quando:

• o objetivo é transporte de dados

• a estrutura existe para comunicação

• a forma do dado varia conforme o uso

• não há regra de negócio envolvida

• a identidade não é relevante

Models ajudam a isolar camadas e evitar acoplamento desnecessário.

Usar um, outro, ou ambos

Em sistemas simples, pode-se usar apenas models sem grandes problemas.

Em sistemas com domínio relevante, a separação costuma ser mais saudável:

• Entities no domínio

• Models para entrada, saída e adaptação de dados

Essa separação evita vazamento de conceitos e mantém cada camada com responsabilidade clara.

Quando você mistura Entity com Model:

• regra de negócio vaza pra API

• mudança de contrato quebra o domínio

• tudo vira acoplamento

• o sistema envelhece mal

Separar não é frescura. É cicatriz de projetos grandes.

Ponto importante

Chamar uma classe de Model ou Entity não muda nada por si só. O que importa é o papel que ela cumpre na arquitetura.

Arquitetura não é nomenclatura. É intenção.

Antigamente já se sabia:

• domínio é estável

• interface muda

• infra muda

• regras sobrevivem

Por isso:

• Entity → núcleo

• Model → periferia

Hoje chamam de Clean Architecture, Hexagonal, DDD… Mas a ideia é velha. E é boa.

Conclusão

• Entity representa o negócio

• Model representa dados para um contexto específico

• Ambos têm papéis diferentes e complementares

• Escolher corretamente reduz acoplamento e aumenta clareza

Usar um ou outro não é questão de moda, é questão de responsabilidade.

Criar a classe Product:

namespace RepositoryStore.Models;

public class Product
{
    public int Id { get; set; }
    public string Title { get; set; } = string.Empty;
}

A partir de agora, a implementação do CRUD dessa classe passa a ser considerada para persistir os dados em algum mecanismo de armazenamento.

Explicação ponto a ponto

Entidade Product

namespace RepositoryStore.Models;

public class Product
{
    public int Id { get; set; }
    public string Title { get; set; } = string.Empty;
}

Namespace do modelo

namespace RepositoryStore.Models;

O namespace indica que a classe pertence à camada de modelos do domínio da aplicação.

Esse agrupamento facilita a organização do código e deixa claro que a classe representa um conceito do domínio, e não um detalhe de infraestrutura.

Definição da entidade

public class Product

A classe Product representa uma entidade do domínio. Ela modela um conceito central que pode ser persistido, recuperado e manipulado pela aplicação.

Identificador da entidade

public int Id { get; set; }

A propriedade Id atua como identificador único da entidade.

• Geralmente mapeada como chave primária no banco de dados.

• Seu valor pode ser gerado pelo mecanismo de persistência (por exemplo, identity no SQL Server).

• Permite a distinção e rastreabilidade das instâncias da entidade.

Propriedade de domínio

public string Title { get; set; } = string.Empty;

A propriedade Title representa um dado essencial do domínio.

• Inicializada com string.Empty para evitar valores nulos.

• Contribui para a consistência do modelo.

• Evita warnings relacionados à nulabilidade.

Observações arquiteturais

• A entidade não contém detalhes de persistência.

• Não depende de Entity Framework ou qualquer ORM.

• Não conhece banco de dados, tabelas ou mapeamentos.

• Pode ser testada isoladamente.

Esse isolamento mantém o modelo de domínio estável e alinhado ao objetivo do Repository Pattern:

proteger o domínio de detalhes técnicos transitórios.

Resumo

A classe Product:

• representa uma entidade do domínio

• é simples, explícita e focada

• não possui dependências de infraestrutura

• está preparada para ser usada por repositórios e regras de negócio

Esse é o ponto de partida correto para um domínio limpo e sustentável.