none
Problema com ValueObject no Entity framework RRS feed

  • Pergunta

  • Boa tarde pessoal estou tendo uma dificuldade com um mapeamento e gostaria de saber se é possível fazer isso:

    Possuo uma classe de Contato com dois campos que são ValueObject do tipo "Telefone", os campos são Telefone e Celular.

    public Telefone Telefone { get; set; }
    public Telefone Celular { get; set; }

    Gostaria de fazer o seguinte mapeamento, de forma que Telefone seja obrigatório e o celular não:

     Property(x => x.Telefone.DDD)
        .HasColumnName("TelefoneDDD")
        .IsRequired();
    Property(x => x.Telefone.Numero)
        .HasColumnName("Telefone")
        .IsRequired();
    Property(x => x.Celular.DDD)
        .HasColumnName("CelularDDD")
        .IsOptional();
    Property(x => x.Celular.Numero)
        .HasColumnName("Celular")
        .IsOptional();

    Quando mando gerar o migration, me retorna o seguinte erro:

    Conflicting configuration settings were specified for property 'Numero' on type 'SistemaTeste.Domain.ValueObject.Telefone': 
    IsNullable = False conflicts with IsNullable = True

    quarta-feira, 6 de abril de 2016 16:34

Todas as Respostas

  • Tira o .IsOptional(); do Celular, certifica se o campo está nulo no banco
    quarta-feira, 6 de abril de 2016 16:54
  • Não, ele colocou tudo como requerido.
    quarta-feira, 6 de abril de 2016 17:10
  • Então coloca como nulo, já que não vai ser obrigatório, se não desmarcar, sempre vai te obrigar a gravar algum valor.
    quarta-feira, 6 de abril de 2016 17:15
  • Aí tenho que mudar o telefone também, pois se eu deixar um como nulo e o outro não ele dá erro. Atualmente solucionei gerando o migrations e alterando o arquivo manualmente da maneira que eu preciso.
    quarta-feira, 6 de abril de 2016 17:21
  • Uma outra alternativa menos elegante seria herdar a classe Telefone, criando uma classe Celular. Porém toda vez que ocorrer isso criar uma outra classe eu perco um pouco da lógica.

    Eu fico imaginando se por algum motivo eu criar um ValueObject mais complexo e precisar usá-lo com mapeamentos diferentes para outras classes, sempre terei que criar classes herdadas para contornar isso. Ex.: Um CPF pode ser obrigatório para uma tabela de cliente e opcional em uma tabela X, se eu trabalhar com tipo primitivo apenas validando se é CPF está ok, mas se eu quiser criar uma classe para encapsular o CPF esbarrarei nesse problema novamente.

    quarta-feira, 6 de abril de 2016 19:46