Como posso modelar um relacionamento "É UM" no EF?
Exemplo:
class Usuario{}
class UsuarioPerfil1 : Usuario {}No banco tenho uma tabela UsuarioPerfil1 com uma chave estrangeira apontando para a chave primária de Usuario.
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
Solucionado
Como posso modelar um relacionamento "É UM" no EF?
Exemplo:
class Usuario{}
class UsuarioPerfil1 : Usuario {}No banco tenho uma tabela UsuarioPerfil1 com uma chave estrangeira apontando para a chave primária de Usuario.
A reposta depende de como tu queres que a atua apliacação se comporte. O mapeamento entre um classe e uma tabela nem sempre é direto. O teu caso é um exemplo, uma vez que bancos de dados relacionais não suportam herança. A isso se dá o nome de incompatibilidade de impedância objeto-relacional (Impedance Mismatch). Nesse contexto, essa imcompatibilidade se refere a uma serie de problemas em representar dados de bancos de dados relacionais em linguagens de programação orientadas a objetos e vice-versa.
Sendo assim, a representação de herança no banco de dados ainda é possivel mas com vantantagens desvantages que devem ser ponderadas de acordo com a necessidade. Por exemplo, há três estratégias diferentes para mapear herança para um banco de dados levando em conta questões como polimorfismo, consistência e performance.
A estratégia mais simples seria uma tabela para uma hierarquia inteira (Table per Hierarchy (TPH)). Nessa estratégia ocorre o seguinte:
-Uma hierarquia de classe inteira pode ser mapeada para uma única tabela.
-A tabela inclui colunas para todas as propriedades de todas as classes nessa hierarquia.
-A subclasse concreta é identificada pelo valor de uma coluna discriminadora de tipo.
Assim tu terias algo como:
public abstract class Person
{
public int Id { get; set; }
public string FullName { get; set; }
}
public class Student : Person
{
public DateTime EnrollmentDate { get; set; }
}
public class Teacher : Person
{
public DateTime HireDate { get; set; }
}E na classe que extende DbContext fica assim:
public class MyContext : DbContext
{
public DbSet<Person> People { get; set; }
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Teacher>();
modelBuilder.Entity<Student>();
}
}Neste exemplo tu ganhas em performance e polimorfirmos mas perde em consistência, uma vez qe a tabela conterá valores nulos . Para fazer uma consulta especificamente por tipo, faça assim:
myContext .People .OfType<Teacher>().ToList()Para CRUD em geral faça:
myContext .People.Find()
myContext .People.Remove() . . .
Há outras duas estratégias. Eu nunca as implementei, mas eu te aconselho a deixar tudo o mais simples possivel. Pois uma vez que o teu projeto cresce, vai ficando cada vez mais difícil lidadar com esses problemas. Espero ter ajudado.
Aqui um aula da Alura sobre isso: https://cursos.alura.com.br/course/entity-framework-core-banco-pre-existente-parte2/task/31242.
Aqui um projeto pessoal em que que implemento herança: https://github.com/RenanCbcc/ekklesia
Fonte: entityframeworkcore