mercredi 16 août 2023

How can we reduce a Multi-Functional Class with conditional logic into Fundamental classes with Specific logic - C# ASP.NET CORE?

In an ASP.NET Core EF application, I have a 'CentralDesignObject' with many types of related data, and a significant amount of derived/calculated values based on the information applied to the 'CentralDesignObject'.

This 'CentralDesignObject' contains a many-to-one relationship with a 'DesignType' object, which defines various fundamental characteristics of the Central Design Object.

While there are broad similarities across all the 'DesignTypes' in terms of the types of related data and in terms of the objects calculation results, there are some calculation methodology differences depending on the 'DesignType'. These are expressed through conditionals within certain calculation routines.

The

CentralDesignObject{

  public Guid DesignObjectId {get; set;}

  public int DesignTypeId {get; set;}
  [ForeignKey("DesignTypeId")] 
  public DesignType {get; set;}
    
  public ICollection<RelatedDataA> RelatedDataA {get; set;}

  public ICollection<RelatedDataB> RelatedDataB {get; set;}

  public CalculationMethod_X() {
  
    if (DesignType.Name == 'foo') {  
      // do x
      return x;
      } else if (DesignType.Name == 'bar') {
      // do y
      // Slightly different result
      return y;
      }
    }
}


`public class RelatedDataA{

    public int RelatedDataAId {get; set;]
   
    public Guid CentralDesignObjectId {get; set;}
    [ForeignKey("CentralDesignObjectId")]
    public CentralDesignObject CentralDesignObject {get; set;}   

    public decimal A {get; set;}

    public decimal B {get; set;}
}

public class RelatedDataB{

    public int RelatedDataBId {get; set;]

    public Guid CentralDesignObjectId {get; set;}
    [ForeignKey("CentralDesignObjectId")]
    public CentralDesignObject CentralDesignObject {get; set;}

    public decimal A {get; set;}
    public decimal B {get; set;}
}

As more 'DesignTypes' are added, the approach has been to add conditional expressions within various calculations as required. The core concept I am trying to get a handle on is how to move away from ever growing conditional loops as the number of 'DesignTypes' grows. My thought was potentially implementing the core of the 'CentralDesignObject' as an base abstract class or interface and then creating Concrete Implementations for each 'DesignType' of the 'CentralDesignObject' as separate classes.

RelatedDataA, RelatedDataB, etc are still all relevant to each of these concrete types. So then it crossed my mind, how would the foreign key relationships on these RelatedData objects be configured when they may be related to ConcreteCentralDesignObjectTypeA , ConcreteCentralDesignObjectTypeB, ConcreteCentralDesignObjectTypeC, etc.

Is there another approach which would be more appropriate? Is it worthwhile to try and make this change at all?

Any thoughts or recommendations on how to approach this kind of problem are appreciated.

Aucun commentaire:

Enregistrer un commentaire