Registering a type by name/assembly - i.e. RegisterType(typeName, assemblyName)

Sep 24, 2008 at 3:46 PM
Is it possible to register a type mapping strictly using strings... i.e. if a configuration source other than a UnityConfigurationSection were being used...

<MyTypeMappings>
    <MyTypeMapping requestedType="MyNamespace.ISomeType"  mappedToType="MyNamespace.SomeImplmentation" />
</MyTypeMappings>

To get around the issue that Unity won't work on the Mobile platform, I was looking to abstract out the Unity specific aspect of configuring the "container" so that I could do something along the lines of a 'provider' model for my Container.  I want the configuration/mapping of types to be container-agnostic and derived from multiple XML files.

It seems all flavors of the Register method require the actual type. But the UnityConfigurationSection is doing it from a config file/strings... So are they doing something under the hood (such as dynamically creating an instance of the type(s) and then passing them into the Register method) ?

What are my options here? I don't mind having to have a verbose XML file that includes Type Name / Assembly name for each type (requested/mapped to)...
Sep 24, 2008 at 9:26 PM
The Unity configuration elements are just doing a Type.GetType(name) on it, and letting the platform do it's thing, and then call the RegisterType method. MSDN says that method works on the compact framework, so assuming you've passed the full namespace and assembly qualified name that should do the trick.


Sep 25, 2008 at 12:19 AM
So it sounds feasible in a sense that I could make a 'poor mans' Container for my mobile apps. I'd just forego using the Container for true DI... All it would be doing is assisting with loose coupling and acting in a "service locator" capacity...

I'm going to try and mock up something so I have a contingency for Mobile in the event the client can not pick the hardware device which runs XP/Vista... But it does mean constraining my design/construction to using the "container" for Interface-to-Implmentation mapping only and no true DI/IoC.... unless I want to spin my own reflection-based code which you in another post aluded to being "very very very slow on mobile"...

So, just to clarify... Unity will NOT run on Mobile at all. Or it's just an un-supported and poor performing choice? I haven't loaded up the Mobile SDK and Emulators for VS yet to try anything myself... And I'd rather not waste time trying if it's a well known fact...

Thanks!
Sep 25, 2008 at 1:52 AM
To clarify your clarification - as far as I know, nobody has ever tried to compile, let alone run, Unity on Mobile. The chances of it compiling without major surgery is pretty close to zero, and even if it does I expect perf would be pretty awful. We have no plans to pursue a Mobile port of the code, so we haven't tried.

Depending on your design choices, you could probably get most of the benefits of true DI/IoC using a delegate based approach. You'd write the delegate for each concrete type to call back into the container to get the needed objects. Unfortunately that doesn't lend itself to configuration files. I've got a few ideas on how to work around this, but I really need to get the regular code done before looking into a whole NEW container. ;-)

-Chris



Sep 25, 2008 at 2:13 AM
Agrreed. I'd rather see these efforts focused on a REAL platform than wasted on Mobile... I wish these small form factor/ruggedized devices would just go all Xp/Vista and Mobile can simply disappear from the face of the Earth! I'm betting I"m not the only one who feels that way! ;-)

Anyhow, I think I see where you're going with the delegate thing... but keep in mind here... I'm trying to write components that will refer to a facade ("MyContainer" lets say - which has the register/resolve methods implemented by a 'provider') and have the same feature set available whether using Unity as one provider or the "lightweight" provider I'd hve to create for when on a Mobile device... So I'm trying to do the old "write once run anywhere" thing... So if I were to go with delegates and my own container that was delegate based for DI... I'd basically end up not needing Unity at all.... And I'm not looking to re-invent the wheel... I want to use what is available of course.

So I think my option for today is to try and force the decision to be on a true Xp/Vista device and use Unity (including the ability to use true DI and not just mapping)... or only use Unity for a "interface-to-concrete implementation" mapping mechanism and forego reflection-based DI... and the Mobile provider would just have to be a light-weight mapping-only mechanism...  Of course then I'd have to consider whether to use Unity at all if the lightweight mobile friendly provider I have to create meets the same needs...

I'm *really* going to push for the device to not be on Windows Mobile. It's just a more strategic decision for the client to not limit themselves and the "platform" with what difficulties/limitations that development for Windows Mobile introduces. The opportunity for component re-use is far greater if the platforms don't have that huge gap that exists between Standard FW/CLR and Compact FW/CLR....

Thanks for your input!