Ggthjy

I have an ASP.NET Core controller I am creating. The controller endpoint looks something like this right now:

[HttpPost("")]

public async Task<ActionResult<Thing>> AddThing([FromBody] string otherThingId)

  {

    // First I perform some validation here (null check, proper ID, etc).



    // Next I get OtherThing to make a Thing out of it

    // _getOtherThing is at the heart of what I'm trying to understand

    var sample = await _getOtherThing(otherThingId);



    // Finally I do some work to convert it to a Thing and send it back

    return newThing;

  }

_getOtherThing is a method that performs a very specific concrete call to another API to get the data I needed. It's a method that takes a string and returns a Task<OtherThing>. There are issues with this method as it is though, such as testing, sharing it in the code base, and swapping implementations later on.

To me, it seems like it's an external dependency. So it would make sense to pass it into the controller. The controller class does with the Repository it uses via DI like so:

public ThingController(IThingRepository thingRepo)

{

  _thingRepo = thingRepo;

}

The interface and its concrete implementation are then supplied for injection in the Startup.cs file:

public void ConfigureServices(IServiceCollection services)

{

  services.AddScoped<IThingRepository, ThingRepository>();

}

So I end up with two questions:

1. What is the most common/expected way to extract this function and then supply it to the controller?


2. If I did want to just supply a function, what is the most reasonable way to do it?

With respect to the first question - Here are two strategies I could think of. Are there others?

1. 
   Supply the function directly to the class. What I came up with looks like this:

public ThingController(IThingRepository thingRepo, Func<string, Task<OtherThing>> getOtherThing)

{

  _thingRepo = thingRepo;

  _getOtherThing = getOtherThing;

}

And then during Startup.cs:

public void ConfigureServices(IServiceCollection services)

{

  services.AddScoped<IThingRepository, ThingRepository>();

  services.AddSingleton<Func<string, Task<OtherThing>>>(

    OtherThingUtils.GetOtherThing

  );

}

2. 
   Convert the function into an interface/class pair and inject that:

interface IOtherThingProvider {

  Task<OtherThing> getOtherThing(string id);

}

class OtherThingProvider : IOtherThingProvider {

  public async Task<OtherThing> getOtherThing(string id) 

  {

    // original code here

  }

}

And then in the Startup.cs file:

public void ConfigureServices(IServiceCollection services)

{

  services.AddScoped<IThingRepository, ThingRepository>();

  services.AddSingleton<IOtherThingProvider, OtherThingProvider>();

}

You basically butcher the entire reason to dependency inject here.
Some IoCs let you deffer injection by doing public MyConstructor(Func<IMyInterface> factory). This is fine, because IMyInterface is an interface and the concrete implementation will be invoked through the standard pipeline and it can have its own dependencies.

But your solution cuts off the DI pipeline half way through and the OverThingUtils.GetOtherThing can not benefit from DI at all. And the special Func<string, IType> construct is dangerously close to service locator pattern.

I would create an interface,

interface IOtherThingProvider 

{

   Task<OtherThing> GetOtherThing(string id);

}