What to do when a model has N responsibilities

7

My system exists a class that is currently a common class for various situations, below some of the other models to exemplify

public class Servico
{
   public int Id {get;set;}
   public string Nome {get;set;}
   public decimal? Valor {get;set;}
}
public class Coleta : Servico
{
    //dados da colheita
}
public class Faturamento
{
    public ICollection<Servico> Servicos {get;set;}
}

Then, this Service can be registered as

var servico = new Servico("Coleta de sangue",5.00);

Service is a% common, just to avoid repeating records and for the user to choose a model o or services, without having to register again

But Coleta is also a service, which may or may not be carried out in the company, if carried out within the company, it will have its other fields ...

But how can I stop when I go through multiple collections, my Service Record List does not get huge? That is, select model is just a simple reference, since Servico is a more complete model, that there may be actions within it

[Edit]

A step-by-step example of the process.

  • Service Registration (Blood Collection)
  • Referenced in a work order
  • If it is done in the company, the TELA is itself, with other fields, etc., represented by the class Collection
  • Go to Billing as a Service
  • What I'm doing, I leave in a Coleta the name of the Blood Collection Service, I do not let the user edit, and when I generate a work order, I generate a constant class if done in the company (it has Coleta.cs a view speaking if done there or by third parties)

    It could also have within the class checkbox , a Coleta.cs , so select it, when to do the Collection, though it is annoying and bad for the user, since it is Blood Collection and not another service, too , if it has many services, it's bad to keep looking.

        
    asked by anonymous 25.11.2015 / 04:55

    2 answers

    3

    In the Entity Framework, in the case of inheritance, the table with the name of the ancestor class, with all the fields of the derived classes, is created, and a column called discriminator . The completion of this extra column is done by the framework itself.

    To specifically address a Service or Collection, create a DbSet<> for each:

    public DbSet<Servico> Servicos { get; set; }
    public DbSet<Coleta> Coletas { get; set; }
    

    If you extract the generated sentence from any IQueryable<Coleta> , you will see that select s, insert s, update s, and delete s refer Servicos , not Coletas .

    Now, if you do not want to use two DbSet<> , no problem: the OfType<> operator resolves which class you want to select:

    var coletasDeServicos = db.Servicos.OfType<Coleta>().Where(...).ToList();
    
        
    25.11.2015 / 14:49
    1

    This will depend on your business rule .

    When you add Collections to your list of services you can perform this treatment.

    For example, you can only have 10 collections in the list, so you're dealing with the method you use to add. By adding checks for many collections and makes the desired decision (may be to delete the older collections or stop including).

    Now if you work in the database, you can add it, but when consulting you can consult only a certain amount. Known procedure for pagination .

        
    25.11.2015 / 11:21