This days I saw a pretty nice idea of implementing the setup part of a DI container – when you make the setup from code and not from configuration file.
Usually when you are working with DI on a big project, you a piece of code for each component (assembly) that register into the container the instances for that component - ContainerInstaller. When you start the application or load a specific container you need to call that specific class end register all the items for that class.
Another solution that I think that is pretty interesting is to define an extension method for each component (assembly) – an extension method of builder. Each component will define internally his own extension method that do the same think as the installer.
Of course this is not a perfect solution and will not work for big project where you need automatically to make this setup. Also, because you define an extension method directly to a specific builder (or container) you will have a direct dependency to the DI container (but how often you change it?).
In conclusion I would say that this is an interesting solution, that can be used with success for small project. This could be a great solution when you define a stack that will be used by others. They will be able to see directly what kind of installer they have available. AND, in the end the extension method can forward the call to an installer class.
Usually when you are working with DI on a big project, you a piece of code for each component (assembly) that register into the container the instances for that component - ContainerInstaller. When you start the application or load a specific container you need to call that specific class end register all the items for that class.
public class FooInstaller
{
public void Install(IContainer container)
{
container.Register<...>(...);
container.Register<...>(...);
}
}
This can be made automatically, if you define an interface like IInstaller. Using reflection or other mechanism you can automatically find this installers and run them.Another solution that I think that is pretty interesting is to define an extension method for each component (assembly) – an extension method of builder. Each component will define internally his own extension method that do the same think as the installer.
public static class FooContainerExtension
{
public static void AdFoo(this IContainer container)
{
container.Register<...>(...);
container.Register<...>(...);
}
}
In the main entry point of the application, you will need to call the extension method for each component.container.AddFoo();
container.AddCore();
container.AddAzureStorageSupport();
This is a nice feature for develops, that don’t need anymore to look over documentation to see which installer they need to call and so on.Of course this is not a perfect solution and will not work for big project where you need automatically to make this setup. Also, because you define an extension method directly to a specific builder (or container) you will have a direct dependency to the DI container (but how often you change it?).
In conclusion I would say that this is an interesting solution, that can be used with success for small project. This could be a great solution when you define a stack that will be used by others. They will be able to see directly what kind of installer they have available. AND, in the end the extension method can forward the call to an installer class.
Comments
Post a Comment