One drawback to the OpenNETCF.IoC framework was the difficulty in making object generation loosely coupled. This is especially true when object types you want to create change depending on your runtime environment. For example let’s say we have an interface IAccelerometerService. Different devices have different implementations, and the emulator and your integration tests don’t even have hardware so they need a simulator. So you create some classes that derive from the interface like this:
public interface IAccelerometerService
public class DeviceAAccelerometer : IAccelerometerService
// handles the accelerometer by using APIs for device A
public class DeviceBAccelerometer : IAccelerometerService
// handles the accelerometer by using APIs for device B
public class SimulatedAccelerometer : IAccelerometerService
// simulates an accelerometer (emulator, test use, etc)
That’s all well and good, but let’s say we have a generic infrastructure module that does the object creation and injection. We don’t want it to have to know about the concrete class types. They might be in separate assemblies that may not even exist – you certainly don’t need (or want) to ship emulator implementation for your hardware.
How would you handle this? The IoC framework doesn’t like the following construct:
Because it has no idea what concrete type you want it to create. In this case it will throw an IOCException.
Today I added a “registration” process to the framework. You now can do the following:
This tells the RootWorkItem that when you call to create an item of type IAccelerometerService, it should actually create an object of type SimulatedAccelerometer.
Each ManagedObjectCollection (so Items, WorkItems, SmartParts and Workspaceas) keeps track of its own Dictionary of type mappings and calling RegisterType on a given WorkItem calls the registration for each. You can explicitly call RegisterType on any one of the collections directly and “override” an existing registration. This means that you could have Items create one type and SmartParts create another type for the same interface. I’m not sure when you’d ever want to do that, but I’ve provided for it.
Hopefully this makes the IoC framework a little more friendly, especially for testing (which is already painful enough for devices), and helps you, as a developer, develop your solutions faster without having to think about the underlying framework.