Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Relacionar tabelas do contexto da aplicação com o contexto do Identity

Pessoal, boa tarde.

A respeito do Curso "APIs Rest com ASP.Net Core 2.1 Parte - 1: Da app MVC para API", especificamente a aula "separando as aplicações" tive uma dúvida conceitual.

O contexto da aplicação (LeituraContext) está separado do contexto de autenticação do Identity (AuthDbContext), inclusivo pelo que ando lendo isto é uma boa prática.

Qual seria a melhor abordagem caso eu quisesse relacionar alguma tabela da minha aplicação com a tabela Usuário que herda de IdentityUser? Para ficar mais claro, um exemplo:

Ao incluir um livro, gostaria que no registro deste livro houvesse uma coluna onde ficasse armazenado o ID do usuário que inseriu este livro. Ou seja, esta coluna seria chave estrangeira relacionada com a coluna ID de AspNetUsers.

4 respostas

Olá Daniel, tudo certo?

Você precisará amarrar o id do usuário ao id do cliente que está vinculado ao pedido na tabela Pedidos por meio da classe UserManager do Identity.

Recomendo o terceiro curso de Asp.NET Core. Nele é ensinado isso, devido ao banco de dados de produtos ser um banco em SQL Server e o de usuários é um em SQLite. Cada banco com seu próprio contexto, mas o código amarra os dois pelo Id do usuário. Ou melhor, as compras ganham o Id do usuário e a partir dele, é possível trazer as outras informações, depois é só vincular os dados do pedido e do usuário.

Espero ter ajudado!

Olá, Fabiano.

Dei uma olhada por alto nos vídeos e parece que ele obtém o ID do usuário através do objeto ContextAccessor que busca no HttpContext, certo?

Se sim esta é a melhor abordagem mesmo? Porque penso em algo de relacionamento de tabelas; primary key e foreign key.

solução!

Isso mesmo.

A classe UserManager amarra os dados que são obtidos do HttpContext pelo ContextAccessor.

Quanto a ser a melhor abordagem, acredito que é sim, pois o relacionamento de tabelas (e banco de dados) aumentaria o acoplamento entre os bancos. Acredito que a separação dos bancos servem justamente para os dois funcionarem um independente do outro, afinal, se o banco dos pedidos mudar, não terá nenhum impacto no banco dos usuários.

Acho que se for para manter todo o acoplamento entre os bancos, compensa mais manter apenas um e todas alterações e tudo mais serem feitas apenas nele.

E outro ponto é que para o pedido é apenas necessário o Id do usuário, e os outros dados são irrelevantes para o próprio pedido. Um sistema de gerenciamento de usuários não precisa saber quais pedidos aquele usuário fez.

O que acha sobre isso?

É uma abordagem interessante, não tinha imaginado antes. Realmente se for algo como o exemplo levantado onde o pedido precisa só do ID do usuário não faz sentido alto acoplamento entre bancos.

Agora, se for algo mais complexo, realmente faz mais sentido ter somente um contexto.

Acredito que solucionamos minha dúvida.

Muito obrigado.