[Update 29-Apr-12] I've revisited Bootstrapper for a new project and it does register the StartupTasks in the IoC container and resolve them from there too (if you have your IoC extension before your StartupTasks) - this means any dependencies your StartupTask should be resolved. I don't know whether BootStrapper always did this or I was just too lazy to find it out - however with this feature you can pretty much disregard the following post!
[Original Post]
I like the Bootstrapper codeplex project - it's a nice clean approach to setting up your application....however...
I have a specific requirement to satisfy as part of my bootstrap process and I'm not sure if Bootstrapper can solve it. I'll be honest I thought it easier to write this post as I wanted to talk about my ideal Bootstrapper as well as someone hopefully telling me if Bootstrapper can do this or not!.
Lets say I have an IoC container that needs configuring - easily done with Bootstrapper.
I also have some components that need running once to perform some one-time registration. These components require some configuration values from the config file (app/web.config). Bootstrapper provides the IStartupTask interface to allow components to perform this - sweet.
I can just make a call to ConfigurationManager in my IStartupTask component(s) to pick up the relevant appSettings right?
Wrong - this sucks....appSettings suck period as they are insidious dependencies that will break your code left right and centre if you don't know what they are. They have a place in the top level application but in "components" that could be used anywhere in the software stack? No, big no. The only way to understand where they are used is to search the code for ".AppSetting" - but what if they are in an assembly you don't have the code at hand to - well you keep trying to run it until you have smoked out all the settings! Bonkers!
What I want is for the IStartupTask components to take a configuration object in the contructor - this makes it explicit and breaks the horrid appSettings dependency.....but....these constructor parameters will only be injected if the IStartupTasks are resolved through my IoC container (giving it a chance to do the injection).
So my ideal Bootstrapper sequence is this....
Initialise the IoC container
Perform automatic programmatic registration (find all container registry/setup components and execute them).
Process Xml config files (this is where we would register our configuration components).
Scan for all IStartupTask implementations and load them into the Container
ResolveAll components from the container and execute them - this would ensure any ctor dependencies would be injected thus providing our configuration values.
I think I can write an extension method to the Bootstrapper to do this but it would be locked to the IoC container (there is no generic reference to get hold of ANY container used?) - not terrible though.
The key would be to introduce a "common service locator" wrapper over your IoC container in order for Bootstrapper to by able to add all IStartupTasks to the container and then perform a "ResolveAll"
...hmmmm, that's a lot of work just to eradicate appSetting references! Are they so bad if they are used just in the IStartupTask components? - These startup components are unlikely to be used anywhere else in the code/stack....
[Original Post]
I like the Bootstrapper codeplex project - it's a nice clean approach to setting up your application....however...
I have a specific requirement to satisfy as part of my bootstrap process and I'm not sure if Bootstrapper can solve it. I'll be honest I thought it easier to write this post as I wanted to talk about my ideal Bootstrapper as well as someone hopefully telling me if Bootstrapper can do this or not!.
Lets say I have an IoC container that needs configuring - easily done with Bootstrapper.
I also have some components that need running once to perform some one-time registration. These components require some configuration values from the config file (app/web.config). Bootstrapper provides the IStartupTask interface to allow components to perform this - sweet.
I can just make a call to ConfigurationManager in my IStartupTask component(s) to pick up the relevant appSettings right?
Wrong - this sucks....appSettings suck period as they are insidious dependencies that will break your code left right and centre if you don't know what they are. They have a place in the top level application but in "components" that could be used anywhere in the software stack? No, big no. The only way to understand where they are used is to search the code for ".AppSetting" - but what if they are in an assembly you don't have the code at hand to - well you keep trying to run it until you have smoked out all the settings! Bonkers!
What I want is for the IStartupTask components to take a configuration object in the contructor - this makes it explicit and breaks the horrid appSettings dependency.....but....these constructor parameters will only be injected if the IStartupTasks are resolved through my IoC container (giving it a chance to do the injection).
So my ideal Bootstrapper sequence is this....
Initialise the IoC container
Perform automatic programmatic registration (find all container registry/setup components and execute them).
Process Xml config files (this is where we would register our configuration components).
Scan for all IStartupTask implementations and load them into the Container
ResolveAll
I think I can write an extension method to the Bootstrapper to do this but it would be locked to the IoC container (there is no generic reference to get hold of ANY container used?) - not terrible though.
Your thoughts?
Comments
Previously, i used the overly ceremonious IGetXXXSettings pattern so i could have proper constructor injection. I then found FubuCore, which has an IOC friendly way of handling config wiring, so i can use EmailSettings in a constructor, and its behind-the-scenes wiring will grab values from whatever provider is setup.
The ioc registration for FubuCore is a bit long ATM, but i create a StructureMap registry for the sucker and forget about it.