What is the best way to resolve an object?

Question

I've written a resolver so I can have a very primitive DI framework. In the framework I allow for a dependency resolver to specify what default types to load if nothing is specified or registered.

However, the way I do the default loading has got me wondering. I'm not sure I'm doing it the best way it could be done.

Example:

T LoadDefaultForType<T>()
{
    T _result = default(T);

    if (typeof(T) == typeof(ISomeThing)
    {
        result = new SomeThing();
    }
    ... more of the same
    else
    {
        throw new NotSupportException("Give me something I can work with!");
    }

    return _result;
}

Update

The use of this would be to get the default object for a given interface in the event that a module or assembly has not configured the interface with a concrete type.

So for instance:

IoC.Resolve<ISomeThing>();

would need to return back to me a SomeThing object if nothing else has been registered to ISomeThing. The LoadDefaultForType in this case is kind of a last ditch effort to use a default (in this case whatever my domain model is).

The Resolve might shed some light on this as well:

T Resolve<T>()
{
    T _result = default(T);
    if (ContainedObjects.ContainsKey(typeof(T))
        _result = (T)ContainedObjects[typeof(T)];
    else
        _result = LoadDefaultForType<T>();
    return _result;
}

Any thoughts? Is there a better way to load default types given that I'm trying to allow for a Convention Over Configuration approach?

Answer 1

public T LoadDefaultForType<T>()
        where T : new()
    {
        T _result = new T();

        return _result;
    }

the code above would be a better way, but im not sure what it is your're trying todo, more information would help give u a better way of doing whatever it is you're trying to achieve.

I suggest taking a look at Unity for dynamically loading types, ie. Dependency injection

Answer 2

Neil's approach is the best if T can be resolved (I think it also has to be in the same assembly?).

Within your class, you could create an internal "registry" of sorts that could be used with System.Reflection to instantiate items without the giant switch statement. This preserves your "convention over configuration" while also keeping you DRY.

Edit

Combined with one aspect of LBushkin's answer to show some working code. (At least, it compiles in my head, and is taken from an example that I know works...)

public T LoadDefaultForType<T>()
{
  try
  {
    string interfaceName = typeof(T).AssemblyQualifiedName;

    // Assumes that class has same name as interface, without leading I, and
    // is in ..."Classes" namespace instead of ..."Interfaces"
    string className = interfaceName.Replace("Interfaces.I", "Classes.");

    Type t = Type.GetType(className, true, true);
    System.Reflection.ConstructorInfo info = t.GetConstructor(Type.EmptyTypes);

    return (T)(info.Invoke(null));
  }
  catch
  {
    throw new NotSupportException("Give me something I can work with!");
  }
}

Note that - as written - it won't work across assembly boundaries. It can be done using essentially the same code, however - you just need to supply the assembly-qualified name to the Type.GetType() method. (fixed - use AssemblyQualifiedName instead of FullName; assumes that interface and implementing class are in same assembly.)

Answer 3

One way would be to have a list of AssemblyQualifiedName pairs, with the first containing the base type and the second containing the child to be insantiated. It could be in your App.config or an XML file or whatever else is convenient. Read this list during start-up and use it to populate a Dictionary to use as a look-up table. For the key, you could use the AssemblyQualifiedName of the base, or perhaps the corresponding Type instance. For the value, you should probably consider getting the ConstructorInfo for the child type.

Answer 4

A better way to load the default types is to provide an add method that stores the type in a hash table. This decouples the dependency container from the registration logic.

You may choose later to change the registration code to read the types from some file or something.

Answer 5

A few of suggestions:

You could create an attribute that can be used to mark the default implementation type of a particular interface. When you attempt to resolve the type, you could search for this attribute on T and use reflection to dynamically instantiate the type.

Alternatively, you could use reflection to search the available (loaded) assemblies or a concrete type that implements the interface. This can be a slow and expensive processes, so it would only make sense if the default case is rare.

Finally, if you're comfortable with naming conventions, you could search for a class that has the same name as the interface but without the leading "I". Not the best approach, but certainly one that can be made to work in a pinch.