Although this question is related to StructureMap, my general question is:
When wiring up components with an IoC container in code (a
What we do on my current project (which uses AutoFac, not StructureMap, but I think it shouldn't make a difference):
We have the interfaces defining external services that the application uses in a core assembly, let's say App.Core
(like your PersonBase).
Then we have the implementations of these interfaces in Services.Real
(like Bob.dll).
In our case we also have Service.Fake
, which are used for facilitating UI testing with dependencies on other enterprise services and databases, etc.
The front-end "client" application itself (in our case, ASP.NET MVC app) references App.Core
.
When the app starts, we use Assembly.Load
to load the appropriate "Services" implementation DLL, based on a config setting.
Each of these DLLs has an implementation of IServiceRegistry that returns a list of the services that it implements:
public enum LifestyleType { Singleton, Transient, PerRequest}
public class ServiceInfo {
public Type InterfaceType {get;set;}
public Type ImplementationType {get;set;}
// this might or might not be useful for your app,
// depending on the types of services, etc.
public LifestyleType Lifestyle {get;set;}
}
public interface IServiceRegistry {
IEnumerable<ServiceInfo> GetServices();
}
... the application finds this ServiceRegistry via reflection and enumerates through these ServiceInfo instances and registers them on the container. For us, this register-all-services lives in the Web application, but it's possible (and preferable in many cases) to have it in a separate assembly.
This way we can isolate the domain logic from the infrastructure code, and prevent "just-this-once" work-arounds where the application ends up depending on a direct reference to the infrastructure code. We also avoid having to have a reference to the container in each Services implementation.
One really important thing if you are doing this: make sure that you have tests that verify that you can create each "top-level" type (in our case, ASP.NET MVC Controllers) with each potential configuration of the IOC container.
Otherwise, it is pretty easy to forget to implement one interface and break huge sections of your application.
You can do xml configuration with StructureMap as well. You can even mix them if you want.
There are also StructureMap Attributes you could put in your Bob class to tell StructureMap how to load the assembly. DefaultConstructor is one I end up using from time to time.
I finally got this sorted out. It looks like this:
IoC Uml http://img396.imageshack.us/img396/1343/iocuml.jpg
with the assemblies
To get it with StructureMap, I needed a custom "ITypeScanner" to support scanning for assemblies:
public class MyScanner : ITypeScanner {
public void Process(Type type, PluginGraph graph) {
if(type.BaseType == null) return;
if(type.BaseType.Equals(typeof(PersonBase))) {
graph.Configure(x =>
x.ForRequestedType<PersonBase>()
.TheDefault.Is.OfConcreteType(type));
}
}
}
So my main code looks like:
ObjectFactory.Configure(x => x.Scan (
scan =>
{
scan.AssembliesFromPath(Environment.CurrentDirectory
/*, filter=>filter.You.Could.Filter.Here*/);
//scan.WithDefaultConventions(); //doesn't do it
scan.With<MyScanner>();
}
));
ObjectFactory.GetAllInstances<PersonBase>()
.ToList()
.ForEach(p =>
{ Console.WriteLine(p.FirstName); } );
The automatic scan option only works when you keep the naming, assembly and namespace conventions. You can manually configure structuremap with a fluent interface. Example:
ObjectFactory.Initialize(initialization =>
initialization.ForRequestedType<PersonBase>()
.TheDefault.Is.OfConcreteType<Bob>());