I started playing with StructureMap recently. I am struggling with how to design my code's interaction with StructureMap when it comes to the configuration and use of plugin keys. If you have any insights or experience with this, please let me know!

1. Configuration via StructureMap.config

Pros:
* Separation of Concerns
  * My pluggable code doesn't have to know that its going to be used with StructureMap. A big pro!
* One Stop Shop
  * One file to look at to figure out how the application is configured.
* "Look Ma, no hands"
   * To change my plugin configuration or add a new plugin type i don't have to recompile.

Cons:
* One Stop Shop
   * I don't know how to make separate config files for each pluggable component, so if I have several components used in different apps, i have to cut and paste config file information between them.
   * This configuration file could get to be pretty big...
* "Silent Death"
   * It doesn't compile, so i won't know if somethings broken till runtime. I haven't learned about it yet, but it looks like StructureMapDoctor could help with this?
* Magic Strings
   * Magic everywhere! One typo and things can get pretty ugly. What do i do about those Plugin Keys? Anyone who wants anything other than the default instance has to know about the magic concrete key string!

2. Configuration via Attributes

Pros:
* Close to Home
   * Information about each pluggable type is local to the type. Makes it easier to find and manage configuration information.

Cons:
* "He knows too much"
   * Each interface and concret class now knows that its a StructureMap plugin family or pluggable type. Not good if i change my mind about which IoC/DI tool to use later.
* Magic Strings
   * Less string magic than the config file, but i've still got those plugin keys that consumers need to know about.
* "Bad Touch"
   * I've gotta change the code to adjust my configuration. Though usually if that happens i'm guess your going to have to recompile anyway...

Magic Plugin Key Solution?

I tried to solve my magic plugin key issue by create a separate plugin key assembly that just has const strings in it for each plugin key. I decided that for each pluggable assembly XXX i had, i would create an assembly XXX.PluginKey. In the PluginKey assembly I put static classes with the same name as the plugin interface that contain nothing but my plugin keys. I made the strings guid's to help discourage people from using the strings to cut and paste. namespace Lou.PracticeApp.DAO.PluginKey { public static class ILouDAO { public const string Default = "0048CF44-DAE6-4f17-A63C-CCED0F860DD7"; public const string Alternative = "DD653B67-20A4-4ae4-A768-49BC3D4E4B2E"; } }

So if I use attribute based config I can setup a plugin family like so:

[PluginFamily(PluginKey.ILouDAO.Default)] public interface ILouDAO { // ... }

And setup a pluggable type like so:

[Pluggable(PluginKey.ILouDAO.Default)] public class LouDAO : ILouDAO { // ... }

And finally retrieve it like this: dao = ObjectFactory.GetNamedInstance<ILouDAO>(PluginKey.ILouDAO.Alternative );

I'm a little iffy on the design decision to make my plugin key class have the same name as the plugin families interface. But at the same time i thought it would make it pretty damn clear what its holding keys for. And I like the syntax look too. So this kind of solves my magic plugin key issue. I'm not sure I like it though, as I have another assembly floating around. Perhaps I've overcomplicated things... but I just don't like those strings!

So please, let me know about which kind of configuration you prefer, why you do, and how you handle your plugin keys. Or other pros / cons i've missed. I'd like to know! If your a fan of a different IoC/DI tool that you think deals with these issues more elegantly, I'd like to know that too.

Peace.