О ComponentModel и отражении

Question

У меня есть функция, которая принимает любой объект, затем он получает значения из свойств или полей, которые он имеет в качестве входных данных.

В настоящее время это выглядит так:

private string GetFieldValue(object o, Field f)
{
 //field.name is name of property or field
        MemberInfo[] mi = o.GetType().GetMember(field.name, MemberTypes.Field | MemberTypes.Property,
            BindingFlags.Instance | BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic | 
            BindingFlags.ExactBinding );

        if (mi.Length == 0) throw new ArgumentException("Field", "Can't find member: " + f.name);

        Object value;
        if (mi[0].MemberType == MemberTypes.Property)
             value = ((PropertyInfo)mi[0]).GetValue(o, null);
        else value = ((FieldInfo)mi[0]).GetValue(o);

Сегодня я прочитал о System.ComponentModel и его классах XXXDescriptor. В чем разница, когда речь идет о производительности, между двумя фреймворками (Reflection & ComponentModel). Будет ли переписывание вышеизложенного с использованием ComponentModel достичь лучшей производительности или гибкости? Единственное другое различие между этими двумя, которые я знаю, - это поддержка виртуальных свойств CM.

Ty.

Answer 1

Разница в том, что ComponentModel является абстракцией над необработанными классами. Это означает, что вы можете определить свойства , которые не существуют - и действительно, именно так DataView / DataRowView представляет столбцы как свойства для привязки данных. Используя ComponentModel, вы можете получить что-то вроде «динамического» даже в 1.1.

Вы можете подумать, что это означает, что ComponentModel медленнее; но на самом деле вы можете использовать эту абстракцию для усиления ... HyperDescriptor делает именно это - используя Reflection.Emit для написания прямого IL для представления свойств, предоставляя гораздо более быстрый доступ, чем отражение или ванильный ComponentModel.

Однако обратите внимание, что по умолчанию ComponentModel ограничен свойствами (не полями). Вы можете сделать это через фасады PropertyDescriptor на лету, но это не очень хорошая идея. В ComponentModel также мало места для свойства «только для записи».

Answer 2

TypeDescriptor (в System.ComponentModel) кэширует внутренне, поэтому он может иметь лучшую производительность, хотя ничто не мешает вам добавить кэш в приведенный выше код. TypeDescriptor использует отражение, хотя и позволяет Вы можете расширить свой объект и добавить свойства и события, которые не подкреплены «реальными» свойствами и событиями. Однако TypeDescriptor не поддерживает поля.

Если бы я был вами, и меня не заботили возможности расширения TypeDescriptor, , и я был бы рад добавить ваш собственный кэш поверх GetMember, , тогда я бы придерживался с отражением.

Редактировать: Стандартное отражение кэшировало MemberInfo объектов начиная с 2.0 - см. MSDN "Использование .NET: избегайте распространенных ошибок производительности для более быстрых приложений" .