Another day in the trunk, another convention found. After all startable
instances have been started in the bootstrapping process, there is very
similar looking convention which acts upon the
INeedBuildUp interface, a
marker interface. The code for it looks like this:
1 2 3 4
For each contract type which is assignable to the
INeedBuildUp type, it
first resolves the contract type (via
and then performs a build up (via
ObjectFactory.BuildUp(object)) on the
When I initially saw this my first reaction was like “Hm, aren’t those two methods doing more or less the same thing?” (new vs. existing instances) Why should you chain them?
As it turns out there’s something wrong with my initial assessment. When
you take a look at the instances marked with the
you recognize some similarities between them:
- The marked classes are mostly WPF controls.
- They’re explicitly registered with their contract type at the container after they have been created.
- They’ve got at least a single writable property marked with the SetterPropertyAttribute. (Property injection is not implicitly performed in StructureMap, it needs to be explicitly configured)
What I’ve missed in the first run is that you can of course register
existing instances for a contract type in the container. When calling
ObjectFactory.GetInstance for the particular contract type, then you
simply obtain a reference to the configured, already existing instance.
sense for inserting dependencies into an instance which was not created
by the IoC in the first place. Is this the case here?
WPF Controls need to have a parameterless constructor in order to work properly with the XAML engine and the WPF-designer. Mh, is WPF-Design-Time-support the origin of this convention? Seems to be, but I’m not 100% sure. Besides that, is this something a convention should be defined for? To be honest, I’m undetermined …