What are the best practicies concerning bootstraping and ioc container? - dependency-injection

Question

Here is my story :
I'm working on a not so large WPF / C# application implementing (for the first time) inversion of control with the help of Unity Framework. It is mostly finished. My problem come from my "bootstrapper" class, in wich I register my types in the Unity container. With the important number of classes involved, my bootstrapper turned to be much more longer than I'd like and despite the comments/regions, to maintain it would be a pain for anyone else than me. So I was wondering if there was a better way to handle registeration. I was thinking, that maybe :
1. "What are you complaining of ? Every one does it this way" Mmmh, I doubt it
2. I have misunderstood the interest of ioc and too much of my classes need registeration. Well, what would be the interest of ioc ?
3. I simply created a ravioli app with too much different classes, I should merge some I think I did my best to find a balance
4.I should not have one macro bootstrapper, but the main one should call specialized ones, one by librairy for example okay, that begins to sound good. After all, the librairies themselves should know better than others what they contain. But I absolutely don't know how to handle it without having my container tramping in every libraries, these having a dependency over Unity...
So, is one of this points good, or did I just miss the post about the nice way to handle registeration, with comfort of maintainability, that anyone use ?
PS : I did not mentioned the technos in tags, because the question seemed to be pretty common to every app working with an ioc container
Edit : Code Added for the bootstrepper (misnamed bootloader)
It's an old version, it has grow longer by now, something like +15-20%
class Bootloader
{
public void Run()
{
#region SPLASH SCREEN
Sequenceur.IHM.Views.SplashScreen screen = new Sequenceur.IHM.Views.SplashScreen();
SplashScreenViewModel screenVM = new SplashScreenViewModel();
screen.Show();
#endregion
#region CONTAINER INITIALIZATION
UnityContainer container = new UnityContainer();
container.RegisterType<IMainWorker, Overseer>();
#endregion
#region DAL REGISTERATION
container.RegisterType<IManageData<Product>, LazyProductFilesManager>();
container.RegisterType<IManageData<Program>, LazyProgramFilesManager>();
container.RegisterType<IManageData<SequenceResult>, LazyResultFilesManager>();
#endregion
#region BOL REGISTERATION
//Sequence preparation
container.RegisterType<IProvideProducts, EagerCancellableProductProvider>();
container.RegisterType<IProvidePrograms, EagerCancellableProgramProvider>();
container.RegisterType<IPrepareSequence, SequenceInitializer>();
//Sequence processing
container.RegisterType<IManagePlugins, MefPluginManager>(new ContainerControlledLifetimeManager());
//Result Persistence
container.RegisterType<IPersistSequenceResult, SequenceResultPersister>();
container.RegisterType<IManageReport, Reporter>(new ContainerControlledLifetimeManager());
#endregion
#region UPDATE REGISTERATION
container.RegisterType<IManageConnection, SqlConnectionManager>();
container.RegisterType<IUpdateProducts, ProductsUpdater>();
container.RegisterType<IUpdatePrograms, ProgramsUpdater>();
container.RegisterType<IUploadResults, ResultsUploader>();
container.RegisterType<IUpdate, DevelopmentUpdater>(new ContainerControlledLifetimeManager());
#endregion
#region HELPERS REGISTERATION
//Hashing
container.RegisterType<IHashString, Sha256StringHasher>();
//Configuration
container.RegisterType<IPersistConfiguration, ConfigurationPropertiesPersister>();
container.RegisterType<IConfiguration, EditableConfiguration>();
//Logging
container.RegisterType<IManageLoggers, NLoggerManager>();
//Messengers
container.RegisterType<IMessagePublisher<Exception>, SimpleMessenger<Exception>>(new ContainerControlledLifetimeManager());
container.RegisterType<IMessagePublisher<AbortRequest>, SimpleMessenger<AbortRequest>>(new ContainerControlledLifetimeManager());
container.RegisterType<IMessagePublisher<ConfigData>, SimpleMessenger<ConfigData>>(new ContainerControlledLifetimeManager());
container.RegisterType<IMessagePublisher<SequenceAction>, SimpleMessenger<SequenceAction>>(new ContainerControlledLifetimeManager());
container.RegisterType<IMessagePublisher<UpdaterStatus>, SimpleMessenger<UpdaterStatus>>(new ContainerControlledLifetimeManager());
container.RegisterType<IMessageListener<AbortRequest>>();
#endregion
#region IHM REGISTERATION
container.RegisterType<ILoadMenuViews, SimpleMenuViewLoader>();
container.RegisterType<IManageScene, SceneManager>();
container.RegisterType<IProvideOD, WinFormOFDialog>();
#endregion
#region CONVERTERS REGISTERATION
container.RegisterType<IConvertModels<Parameter, dbParameterResult>, ParameterModelsConverter>();
container.RegisterType<IConvertModels<SequenceActionResult, dbActionResult>, ActionModelsConverter>();
container.RegisterType<IConvertModels<Tag, dbTag>, TagModelsConverter>();
container.RegisterType<IConvertModels<Country, dbCountry>, CountryModelsConverter>();
container.RegisterType<IConvertModels<Segment, dbSegment>, SegmentModelsConverter>();
container.RegisterType<IConvertModels<Caracteristic, dbCaracteristic>, CaracteristicModelsConverter>();
container.RegisterType<IConvertModels<Value, dbValue>, ValueModelsConverter>();
container.RegisterType<IConvertModels<Range, dbRange>, RangeModelsConverter>();
container.RegisterType<IConvertModels<Subrange, dbSubrange>, SubrangeModelsConverter>();
container.RegisterType<IConvertModels<Product, dbProduct>, ProductModelsConverter>();
container.RegisterType<IConvertModels<Program, dbProgram>, ProgramModelsConverter>();
container.RegisterType<IConvertModels<Tag, dbTag>, TagModelsConverter>();
#endregion
#region START
ShellView mainView = new ShellView();
mainView.DataContext = container.Resolve<ShellViewModel>();
screen.Close();
mainView.Show();
#endregion
}
}

Answer 1

The famous Mark Seemann has written a blog post explaining when to use a DI container. What he basically says is that the usefulness of a DI container is limited when only use 'Explicit Register', having a line of code per registered type in the container (which is what you are doing). The real benefit starts when you use a Convention over Configuration. With convention over configuration you will be able to register a large amount of types in a single line of code, and you prevent your composition root from becoming this maintenance nightmare.
Although I'm not exactly on the same page and see some use for the 'Explicit Register' model, he is right that you gain the most benefit from using convention over configuration. In your application there are already a few clear spots where you would benefit from convention over configuration and that's when registering your generic abstractions such as IManageData<T>, IConvertModels and IMessagePublisher<TMessage>.
So what you can do is create the following convenient extension method:
public static void RegisterManyForOpenGeneric(this UnityContainer container,
Type openGenericServiceType, params Assembly[] assemblies)
{
container.RegisterTypes(
from type in AllClasses.FromAssemblies(assemblies)
where type.GetInterfaces().Any(i => i.IsGenericType &&
i.GetGenericTypeDefinition() == openGenericServiceType)
select type,
WithMappings.FromMatchingInterface,
WithName.Default);
}
With this extension method you can reduce the registrations of your generic abstractions to the following:
var assemblies = AppDomain.CurrentDomain.GetAssemblies();
container.RegisterManyForOpenGeneric(typeof(IManageData<>), assemblies);
container.RegisterManyForOpenGeneric(typeof(IConvertModels<,>), assemblies);
container.RegisterManyForOpenGeneric(typeof(IMessagePublisher<>), assemblies);