DanielCunha.Toolkit.MappedServices 1.0.1

Mapped Services

The idea of this package is to make it easier to work with dependency injection in ASP.NET Core.

Basically, it contains an attribute which can be used to automatically add your services to the service collection.

This spares you from adding all your services manually to the service collection. All you have to do is to call services.AddMappedServices() in your Startup.cs class and the work will be done.

Motivation

Create an ease to use feature which automatically map contracts (Interfaces) and implementations (Classes) into services and add them to the service collection.

Installation

Install NuGet package DanielCunha.Toolkit.MappedServices or download repo and compile it manually so you can reference it from your target project.

Usage

All you have to have is to add the MappedServiceAttribute to your classes, call services.AddMappedServices() in the ConfigureServices method of your Startup class and all the work will be done by the package. Here's an example:

public interface IUserService
{
    Task<User> AuthenticateAsync(string email, string password);
}

[MappedService]
public class UserService : IUserService
{
    public Task<User> AuthenticateAsync(string email, string password)
    {
        // Your implementation...
    }
}

public class Startup
{
    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMappedServices();

        // Other services...
    }
}

And that's all! Using this feature you can inject as many services you want to just by adding a attribute to your class, without touching in the Startup class every time.

MappedServiceAttribute

The attribute have some properties to make it easier to use it: Scope, InheritedType and InheritedTypeName.

The first one is basically the scope of the service which can be Scoped, Transient and Singleton. The default value is Scoped. Read more about scopes in this article.

The other two are basically an explicitly way of mapping a service to its contract. Usually, if you don't use any of them, the package will look to an inherited type with the name format of "I" + the name of the service (UserService and IUserService for example).

Otherwise, if you use one of them, it will use the informed type or look for an interface with the informed name. It will always prefer to use the type instead of the name in case you pass both.

Contribute

Fell free to clone this repository and modify the project as you wish. I'll glad to add your changes to the next version of the package!

License

MIT License.