Implement Dependency Injection

[Ruhrpottpatriot]

ref #34 #5

[sliekens]

Here's a good blog post from someone much smarter than me: http://blog.ploeh.dk/2014/05/19/di-friendly-library/

Mark wrote a book called Dependency Injection in .NET. I think that every decision here should be based on his book and articles.

[Ruhrpottpatriot]

I think we should go with the netcore dependency injection. It's simple and easy to used and adapters into more popular frameworks such as Autofac, StructureMap, etc. exist.

Registering modules is done via an extension method (as it is recommended on Github/MSDN), much like this:

public static IServiceCollection AddBuild(this IServiceCollection serviceCollection)
{
    serviceCollection.RegisterScoped<IBuildService, BuildService>();
    serviceCollection.RegisterScoped<IConverter<BuildDto, Build>, BuildConverter>();
    return serviceCollection;
}

This gives us everything we need and we can put everything together in the GW2.NET main app.

I'm just thinking how we can implement configuration for the various parts. In ASP.NET you can do something like this: serviceCollection.AddMvc(opt => { /* Some Options*/ }); whereas the options are of type MvcOptions, which is a class that has multiple properties that control the mvc pipeline. We can do the same for us, but I'm not sure how to get the options to the actual object.

[sliekens]

Can this be completely optional? As in you should be able to use a ServiceCollection to resolve services without taking away the option to construct services manually.

[Ruhrpottpatriot]

Yes and no. The services and converter won't be made into internal/protected classes but will stay public, so the user can choose to manually create an instance of, say, BuildService and BuildConverter. However, does that mean we should encourage him to do so? No, not really.

I'm still thinking how we can make the api endpoints available in a type safe way. I found a way around the configuration problem (enter: Factory, which I totally missed), but not this one.