Pular para o conteúdo principal

Relacionamento 1x1 no EFCore

Em uma relação Um-para-Um (1:1) no Entity Framework Core, o método .HasForeignKey precisa especificar qual classe contém a chave estrangeira física no banco de dados.

Um Exemplo

Assumindo que Empresa é a entidade principal e ela possui os IDs de Endereço e Contato:

C#
modelBuilder.Entity<Empresa>(entity => {
    // Relacionamento com Endereco
    entity.HasOne(e => e.Endereco)
        .WithOne(e => e.Empresa)
        .HasForeignKey<Empresa>(e => e.EnderecoId) // <--- Especifique a classe aqui
        .OnDelete(DeleteBehavior.NoAction);

    // Relacionamento com Contato
    entity.HasOne(e => e.Contato)
        .WithOne(c => c.Empresa)
        .HasForeignKey<Empresa>(e => e.ContatoId) // <--- Especifique a classe aqui
        .OnDelete(DeleteBehavior.NoAction);
});

Por que isso é necessário?

Diferente de uma relação 1:N (onde a FK sempre fica no lado "N"), na relação 1:1 a chave estrangeira poderia estar em qualquer uma das duas tabelas.

  • Entidade Principal: É a que existe por si só (ex: Empresa).

  • Entidade Dependente: É a que contém a FK apontando para a principal (no seu caso, se o EnderecoId está na tabela Empresa, a Empresa tecnicamente é a dependente do Endereco).

Dicas Importantes

  1. Tipagem do ForeignKey: Se o EnderecoId estiver dentro da classe Empresa, você usa .HasForeignKey<Empresa>(...). Se o ID da empresa estivesse lá na tabela de endereço, você usaria .HasForeignKey<Endereco>(...).

  2. Chave Única: O EF Core criará automaticamente um índice Unique para essas FKs, garantindo que um Endereço não seja usado por duas Empresas diferentes, mantendo a regra de 1:1.

  3. Nullable: Se uma Empresa puder existir sem endereço, certifique-se de que a propriedade EnderecoId na sua classe seja opcional (int? ou Guid?).

Comentários

Postagens mais visitadas deste blog

UML e comunicação entre Componentes

(conteúdo gerado com I.A.) Antes de abordarmos o conceito de Componentes, vale a pena analisar como um programador iniciante costuma estruturar uma aplicação. Geralmente, a escolha é construir um monólito tradicional, agrupando todas as classes de domínio (como Categoria, Produto, Compra, Venda, Pagamento, etc.) em uma única pasta de Entidades. Da mesma forma, criam-se pacotes globais para Repositórios, Serviços e Controllers. O grande problema dessa abordagem é que ela gera um forte acoplamento entre as classes e as camadas do sistema. À medida que a aplicação cresce, isso desencadeia uma série de dificuldades: Manutenção e modelagem complexas: As responsabilidades se misturam. Rapidamente, o código passa a ter diversos trechos onde as classes assumem funções que não deveriam ter, tornando a evolução do sistema confusa. Escalabilidade ineficiente: Para escalar o backend, é necessário replicar a aplicação inteira e todo o banco de dados. Além de consumir mais recursos, isso traz o ri...

Quando escolher Flask ou Quart no Python

Atualmente , considerando o suporte assíncrono já presente no Flask, a escolha entre Flask e Quart para uma API Server depende de vários fatores técnicos. Vejamos alguns critérios: Fonte:  https://pt.stackoverflow.com/questions/51268/qual-a-diferen%C3%A7a-entre-comunica%C3%A7%C3%A3o-ass%C3%ADncrona-e-s%C3%ADncrona Suporte Assíncrono : Flask : O Flask oferece suporte assíncrono por meio de extensões de terceiros, como  flask[async] . No entanto, seu desempenho assíncrono é inferior aos frameworks nativamente assíncronos. Quart : O Quart é uma reimplantação do Flask baseada no padrão ASGI (Asynchronous Server Gateway Interface). Ele utiliza E/S assíncrona em todo o código e é mais adequado para bases de código predominantemente assíncronas. Desempenho : Flask : Como aplicação WSGI, o Flask usa um único worker para cada ciclo de solicitação/resposta. Quando uma solicitação chega a uma visualização assíncrona, o Flask inicia um loop de eventos em uma thread, executa a função da vi...

Metodo para criar relacionamento entre tabelas sem dar erro cíclico EFCore

Quando estamos modelando o banco de dados no Entity Framework Core (ou em qualquer outra ferramenta) é muito comum criarmos o erro cíclico. Este erro ocorre devido ao banco de dados não conseguir determinar onde o relacionamento termina, causando um erro de loop. Vejamos uma situação real onde foi gerado esse problema: Um Professor leciona em várias Turmas, Um Professor leciona uma ou mais Disciplinas, Um Professor leciona determinadas Disciplinas em determinadas Turmas, Uma Turma tem muitos Professores, Em todas as Turmas tem 9 Disciplinas. Em todas as turmas podem ter até 9 Professores. Só por essa descrição já é possível perceber que os relacionamentos podem ser complexos de entender. E tem-se também o problema da navegação em via dupla: Professor-Turmas, Turma-Professores. Então, como modelar essas tabelas sem que o banco entre em loop? Para resolver esse problema no Entity Framework Core e evitar o erro de "Multiple Cascade Paths" (caminhos múltiplos de cascata) comum n...