'(ASP.Net Core API, EF Core) Issue Registering Interface Attached to Class with 2 Children

I've tried quite a few different things and have tried every magic Google search word I could think of. If I missed something, feel free to virtually slap me and point out what is probably obvious.

Anyways, I am building an API that, without getting into too many details, will handle a couple different types of order submission. Let's call them type A and B. There are quite a few similarities between those two types, so I made one interface and a parent class to handle them both. I then made two children classes that inherit from the parent class and those children handle all the stuff specific to their respective type. The controller calls the thing that gets the order type, calls something from the parent class, and then calls the appropriate child class. So the idea is:

  1. Interface IOrderSub
  2. Parent class OrderSub - inherits from IOrderSub
  3. Child class OrderSubTypeA - inherits from OrderSub
  4. Child class OrderSubTypeB - inherits from OrderSub

This is where it all breaks down. I am having a rather "fun" time trying to register IOrderSub and those classes. I keep getting an error that I am trying to convert IOrderSub to OrderSub once the code hits:

var app = builder.Build();

in Program.cs.

Things I have tried:

  1. Having the child classes inherit from IOrderSub.
  2. Having the child classes inherit from IOrderSub and OrderSub.
  3. Creating an enum of the order types and using AddTransient<>, Func<>, and a case-switch to determine the order type to register in Program.cs. Visual Studio skips over this whole line when I step through.
public enum ServiceType
    {
        TypeA,
        TypeB,
        Parent
    }
builder.Services.AddScoped<TypeA>();
builder.Services.AddScoped<TypeB>();
builder.Services.AddScoped<Parent>();

builder.Services.AddTransient<Func<ServiceType, IOrderSub>>
    (serviceTypeProvider => key =>
    {
        switch (key)
        {
            case ServiceType.TypeA:
                return serviceTypeProvider.GetService<OrderSubTypeA>();
            case ServiceType.TypeB:
                return serviceTypeProvider.GetService<OrderSubTypeB>();
            case ServiceType.Parent:
                return serviceTypeProvider.GetService<OrderSub>();
            default:
                return null;
        }
    });
  1. All different manners of things inside AddScoped<> for the interface and classes.
  2. Having child interfaces that inherit from the parent IOrderSub and having each of the child classes inherit from their respective child interface.
  3. Combinations of the above things.
  4. Various other things I can't remember. The above 6 are what are coming to mind. I've been at this at least a couple days.

I would prefer to keep the class inheritance as I think it just makes sense in this situation due to how similar yet different the two order types are. I did get everything to a point where there are no syntax errors, but I still run into that runtime error.

Anyone have any ideas on how to get this to work, please? I tried to provide as much information as I could, but I'll keep an eye out to see if more is needed.

Thank you!



Solution 1:[1]

Thanks to someone asking for the code and my having to go through it with a very fine-toothed comb to remove all references to DB tables and what-not, I realized the issue described above existed between my keyboard and my chair. I had forgot I had made OrderSub abstract in an attempt to get Visual Studio to stop yelling at me that a method defined in IOrderSub was not in OrderSub (abstract class, defined that method abstract in OrderSub).

I removed any reference to abstract and method overrides and just defined the method as normal. Apparently I had never tried this rather simple solution, as I could just put "new" on the methods in the two child classes and the OrderSub method declaration was effectively "hidden". Not that that is relevant to this. Maybe I'll make a separate question and answer it myself for this issue.

Have a good day all!

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Quicksting