Correct Statement Classes Model MVC Ninject

Question

I started using OO a short time and in all projects I see on the net, I see the following way of statement.

public class Trabalhador
{
    public int Id { get; set; }
    public string Nome { get; set; }
    public virtual ICollection Dependente { get; set; }
    public virtual ICollection Dependente { get; set; }
    public virtual ICollection LicencaMedica{ get; set; }
}

public class Dependente
{
    public int ID { get; set; }
    public string Nome { get; set; }
    public virtual Trabalhador Trabalhador { get; set; }
}

public class Ferias
{
    public int ID { get; set; }
    public string Nome { get; set; }
    public virtual Trabalhador Trabalhador { get; set; }
}

public class LicencaMedica
{
    public int ID { get; set; }
    public string Nome { get; set; }
    public virtual Trabalhador Trabalhador { get; set; }
}

However I am working on a project together with other developers, and one of them argues tooth and nail that my classes should not have "virtual" as a navigation attribute, he argues that the Dependent classes, Holidays and License because they already have an Icollection in Worker, they should not have any key, as they will all be accessible from the working class, is that correct from the point of view of OO? I expressed my opinion and said that this was wrong, because I would be kind of creating a Root class and everything would go through it without need, kind of overloading a class with a lot of responsibility, his approach would be the following:

public class Trabalhador
{
    public int Id { get; set; }
    public string Nome { get; set; }
    public virtual ICollection Dependente { get; set; }
    public virtual ICollection Dependente { get; set; }
    public virtual ICollection LicencaMedica{ get; set; }
}

public class Dependente
{
    public int? ID { get; set; }
    public string Nome { get; set; }
}

public class Ferias
{
    public int? ID { get; set; }
    public string Nome { get; set; }
}

public class LicencaMedica
{
    public int? ID { get; set; }
    public string Nome { get; set; }
}

Is this correct from the point of view of OO? For me to have access to an object of the daughter class I must necessarily pass by the parent class? According to him the Ninject who accuses error in the system, because the fact of instantiating the parent class and then instantiating the daughter class according to him would give a loop in the system, so he rips off all navigation property of the daughter classes.

(We are not using Entity, we are using ADO with SP in the Bank). I tried to be as specific as possible, what is the problem of each of the approaches?

Answer 1

Not that the approach is wrong, but she’s expensive, computationally speaking.

Not having the properties of foreign keys in the relations from 1 to N makes the application have to necessarily load the complete object, which, even with caches and everything else, makes the application slower. For performance, your colleague’s proposal is terrible.

Having foreign key properties in the class does not contradict the OO proposal because an entity class maps a database table, that is, all columns. It is wrong when a column is not mapped just because it is a foreign key (the object does not canonically represent a record of a table or database collection). In addition, the object can be partially loaded when there is no need to load the related entities, without any loss of information. For example, if I just want the name of Trabalhador, do not need to load your dependents. All information about the worker is in the object of the class Trabalhador.

Regarding the use of virtual, it is important to clarify: virtual is used for classes that can be derived. That is, if for example a Dependente is derived to other classes (dressing on Conjuge or else Irmao), the object would no longer accept the object or the collection. The architect of the solution would have to make sure that all classes of entity are immutable, which honestly does not help at all in the development.

By the way, modeling is not canonical. I propose below another modeling more within the best standards used today for development in Asp.net-mvc:

public class Trabalhador
{
    // Usar apenas 'Id' como nome da propriedade pode gerar confusão na montagem
    // de sentenças comparativas, onde não esteja claro qual objeto está sendo manipulado.
    [Key]
    public int TrabalhadorId { get; set; }
    [Required]
    public string Nome { get; set; }

    public virtual ICollection<Dependente> Dependentes { get; set; }
    // Não é preciso duas ICollection iguais, então comentei a segunda.
    // ICollections são tipadas, com o nome da propriedade no plural.
    // public virtual ICollection<Dependente> Dependentes { get; set; }
    public virtual ICollection<LicencaMedica> LicencasMedicas { get; set; }
}

public class Dependente
{
    [Key]
    public int DependenteId { get; set; }
    // Ter uma chave estrangeira aqui não é errado porque cada propriedade
    // que não seja 'virtual' possui uma coluna correspondente em uma tabela no banco
    // de dados.
    public int TrabalhadorId { get; set; }

    [Required]
    public string Nome { get; set; }
    public virtual Trabalhador Trabalhador { get; set; }
}

public class Ferias
{
    [Key]
    public int FeriasId { get; set; }
    public int TrabalhadorId { get; set; }

    [Required]
    public string Nome { get; set; }
    public virtual Trabalhador Trabalhador { get; set; }
}

public class LicencaMedica
{
    [Key]
    public int LicencaMedicaId { get; set; }
    public int TrabalhadorId { get; set; }

    [Required]
    public string Nome { get; set; }
    public virtual Trabalhador Trabalhador { get; set; }
}