Functional dependency injection with ASP.NET?

[EivindAntonsen]

Hi there,
I've been learning more and more about this library, and now I am a bit stuck on bridging functional dependency injection with what's available to use in ASP.NET with web api type projects etc.

So I've just started using Runtimes and trait interfaces. This discussion here showcases the type of runtime usage I'm curious about how to fit into an ASP.Net type project (if at all possible - I'm getting the impression that is not a match meant to be!). You can only register reference types as services using the servicebuilder in an asp.net web api project, and the Runtime as seen in this example is of course a struct. How decoupled from ASP.Net will I have to go to use mostly functional principles?

In short - a regular project with controllers, service layer, data access - where does functional dependency injection fit in?

[bmazzarol]

@EivindAntonsen If you create your runtime with an internal class based environment the integration is relatively straight forward.

// some runtime
public readonly struct Runtime :
        HasActivitySource<Runtime>,
        HasConsole<Runtime>,
        HasFile<Runtime>,
        HasTextRead<Runtime>,
        HasTime<Runtime>,
        HasEnvironment<Runtime>,
        HasDirectory<Runtime>
    {
        readonly RuntimeEnv env; // this holds your service instances  and can be constructed via DI and passed into the runtime

So then you create the RuntimeEnv via DI and pass that to the runtime and you are done.

var env = serviceProvider.GetRequiredService<RuntimeEnv>();
var rt = new Runtime(env); // or via a constructor function Runtime.New(env)
...

Now its integrated. The only requirement is that the env needs to be a class or record.

public record RuntimeEnv(
        ActivityEnv Activity,
        CancellationTokenSource Source, 
        CancellationToken Token, 
        Encoding Encoding);

At this stage IMHO I dont think it needs to be any more complicated than that.

Just wire it into the service collection,

// wire it in however you want
services.AddScoped(sp => new RuntimeEnv(...));

[davidyu2023]

Can you also advise using FP with DI in general? If the construction of a class can incur errors, can it still be injected with DI? I am in a situation where I seem to have a need for repository classes, but the building of those classes may incur errors. Do you think it's a good idea to have the classes hold their state in a Validation<FAIL, SUCC> so that the construction of the classes can never fail? Then they can be supplied with DI. I suspect there are better ways...

[bmazzarol]

@davidyu2023 I'm not sure that I can advise in the general case.

I think I would need more information about the problems you are trying to solve.

I can offer some context based on what I know (think I do anyway).

DI in netcore is just an untyped dictionary from Type descriptor to constructor function. A great resource that talks about why this not a great way to manage dependencies is Mark Seemann. He wrote the book on DI and thinks its a bad idea, I agree with him. Typed DI containers are either lying (ZIO's Has type uses type level magic available in Scala to hide the fact that its just an untyped dictionary) or use source generators to build up the composition root, the same way that Mark outlines in his pure DI piece.

DI containers are impure and untyped by design, best thing you can do with them is get what you need out of them and move back into the realm of pure functional code. Also make sure you always have an integration test that covers building the container and getting the services you need out.

This is why the typed environment outlined here and implemented in Aff and Eff are so much better. They are typed, fully testable and enforce a form of pure DI on the application by design.

[davidyu2023]

@bmazzarol thanks and this is really helpful. I went through the sample coding for Runtime injection, and it is great! And I wonder it can be called Pure DI as it seems a really good fit.

[EivindAntonsen]

@bmazzarol Thanks for your response! This looks helpful. These traits you've defined there, are they found in the library or are they something you crafted from scratch?

[bmazzarol]

All standard library traits. Check out the Sys and SysX projects.

…

On Sun, 19 Mar. 2023, 6:44 pm Eivind Antonsen, ***@***.***> wrote: @bmazzarol <https://github.com/bmazzarol> Thanks for your response! This looks helpful. These traits you've defined there, are they found in the library or are they something you crafted from scratch? — Reply to this email directly, view it on GitHub <#1188 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAV7ZLSDM54ZO45A5D75JIDW43PQJANCNFSM6AAAAAAUVLLUJI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[EivindAntonsen]

Thank you. This is very new to me, do you know of any minimal working sample of this kind of setup that I could take a look at? The description above is very helpful, but seeing it all come together in a program.cs or similar would be great.