A new small opensource library - Autojector.

Scăueru Cristian-Ștefăniță — Mon, 14 Mar 2022 07:50:40 +0000

In the past couple of weeks, I’ve been working on a small library that (I hope) will make the dependency injection from Microsoft easier to use.

The purpose of this library would be to declare in the definition of the class (service) the intended life span.

Either by implementing an interface


public interface ISimpleInjectedService
{
    string GetData();
}

internal class SimpleInjectedService : 
        ISimpleInjectedService, 
        ITransient<ISimpleInjectedService>
{
    public string GetData() => "SomeData"
}

Or by adding an attribute to the service stating which interface represents

public interface ISimpleInjectedByAttribute
{
    public string GetData();
}

[Transient(typeof(ISimpleInjectedByAttribute))]
internal class SimpleInjectedByAttribute : ISimpleInjectedByAttribute
{
    public string GetData() => "SimpleInjectedByAttribute";
}

After that, you can just add this to your startup

builder.Services.AddAutojector();

These are all the steps in order for your ISimpleInjectedService to be injected anywhere by the dependency injection system.

app.MapGet("/simple-injected-service", (ISimpleInjectedService simpleInjectedService) =>
{
    return simpleInjectedService.GetData();
});

While the Simple injection is the simpler way you can use the Autoinjector you can also use :

A Factory to provide your service in a more elegant way

public interface IFactoryInjectedService1 {
    string GetData();
}
internal class Factory1 : ITransientFactory<IFactoryInjectedService1>
{
    public IFactoryInjectedService1 GetService() => new FactoryInjectedService1();
}

An Async factory to provide something that could take longer
Decorators where you can implement the same interface multiple times and keep the previous implementation with composition
Configs which can be used to declare classes or even interfaces as configs
And Chains the most complex feature that still needs direction. With this feature, I would like to implement the chains of responsibility.

Here are the benefits that I think this library would bring:

Would make it easier to see the lifetime of the service right from the implementation
Would make you get rid of the file where you have to add all the services from your class libraries
Would make it easier to come up in the future with abstraction over which DI library you are going to use
All the other features would make it simpler to inject a lot more elegant and structured

Here is a list of cons that I see:

You get rid of DI library dependency but you will be dependent on Autojector.Abstraction

You can check everything for this library here on the website, GitHub or Nuget

Would be nice to hear your opinion in regards to this so: If you have any input please leave it anywhere reachable by me.

It would be nice if you could say :

Why would you use it? Why would you not use something like this?
What more needs to be added in order to be needed?
Other prons? Other cons?

DEV Community: Scăueru Cristian-Ștefăniță

A new small opensource library - Autojector.