Compare type of IEnumerable<T>

I have dictionary that gives me back a method according to the value passed in. Defined as so:

Dictionary<Type, IXmlWriterConverter>

I have now added a new function that which has the Key/type set to IEnumerable, so far so good. But when I execute my unit test with a List containing two DataTables but the dictionary can not find the key e.g. my type conversion differs.

Why is that so? And what would be the right attempt to solve my problem?

Edi开发者_如何学编程t: Sorry here is the requested code ;-)

Function that generates the testvalues:

public IEnumerable<DataTable> CreateTestDataTableList()
{
    var resultDataTable = new List<DataTable>();

    resultDataTable.Add(CreateTestTable("testTable1", 2));
    resultDataTable.Add(CreateTestTable("testTable2", 3));

    return resultDataTable;
}

Function called by the unit test:

public void Write(XmlWriter xmlWriter, object value)
{
    ...
    converter = FindConverter(value.GetType());
}

Function checking the dictionary:

public IXmlWriterConverter FindConverter(Type type)
{
    if(Converters.ContainsKey(type))
    {
        return Converters[type];
    }
    return null;
}

2.Edit:

Code that adds the values to the Dictionary:

public void Add(IXmlWriterConverter xmlWriterConverter)
{
    if(Converters.ContainsKey(xmlWriterConverter.InputType))
    {
        Remove(xmlWriterConverter);
    }

    Converters.Add(xmlWriterConverter.InputType, xmlWriterConverter);
}

The InputType is a readonly (get) property of the converter. I checked the type added to the dictionary and that was registered as IEnumerable, however when I checked on the typeof when passing in my list the type was List and not IEnumerable. I was told that this happens because I pass in the values as object.

This is a really code-stinky solution to me, and it cuts down on the efficiency, but you can also iterate through the GetInterfaces() method on Type, like this:

List<DataTable> l = new List<DataTable>();
var t = l.GetType();
var ints = t.GetInterfaces();

Then you could do a lookup on the type, and, if that doesn't work do a lookup on it's interfaces.

However, this feels like a terrible hack, which usually indicates that some more design work needs to be done. Is it not possible to put the List type in the dictionary? Is there no better way of doing this lookup?

Also, a note on doing dictionary lookups: It's more efficient to use the TryGetValue method, like this:

public IXmlWriterConverter FindConverter(Type type)
{
    IXmlWriterConverter converter;
    if( Converters.TryGetValue(type, out converter) )
    {
        return converter;
    }

    return null;
}

When you do it this way, it only does one lookup on the dictionary, whereas if you use ContainsKey it has to do two lookups.

Its a bit of hack but the only thing that gets into my mind when looking at your code, is to add an other generic write method:

public void Write<TValue>(XmlWriter writer, TValue value) {
// ...
}

This allows to identify the right type for IEnumerable and leaves the other Write method to not break any existing code.

Probably you are trying to retrieve List type and not IEnumerable (inheritance is not going to work in this context)

Please paste the code that does the lookup if you want more details and more certain answer :)

You should also post the code of where you are retrieving the test values. But based on what you've given, are you possibly using the non-generic IEnumerable to retrieve the values instead of the generic version that you're using to generate them?

The InputType is a readonly (get) property of the converter. I checked the type added to the dictionary and that was registered as IEnumerable, however when I checked on the typeof when passing in my list the type was List and not IEnumerable. I was told that this happens because I pass in the values as object.

Like they say on MythBusters, well, there's your problem! Even though List is-a IEnumerable the Type objects that represent each are definitely not the same. In programmer jargon, typeof(List) != typeof(IEnumerable). That is why the lookup is not working.