DEV Community

Scăueru Cristian-Ștefăniță
Scăueru Cristian-Ștefăniță

Posted on

A new small opensource library - Autojector.

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"
}
Enter fullscreen mode Exit fullscreen mode

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";
}
Enter fullscreen mode Exit fullscreen mode

After that, you can just add this to your startup

builder.Services.AddAutojector();
Enter fullscreen mode Exit fullscreen mode

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();
});
Enter fullscreen mode Exit fullscreen mode

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

  1. 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();
}
Enter fullscreen mode Exit fullscreen mode
  1. An Async factory to provide something that could take longer
  2. Decorators where you can implement the same interface multiple times and keep the previous implementation with composition
  3. Configs which can be used to declare classes or even interfaces as configs
  4. 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 :

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

Top comments (0)