2009-04-16 2 views

ответ

5

Основное отличие заключается в том, что это позволяет захватить больше контроля, если вы предоставите свой собственный PropertyDescriptor реализации (через ICustomTypeDescriptor, TypeDescriptionProvider или TypeConverter). Затем вы можете выбрать свою свою логику, когда она может быть записана - например, на основе прав доступа.

Но да; при реализации по умолчанию он будет сообщать только для чтения о свойствах без сеттеров и для свойств, помеченных ReadOnlyAttribute.

+1

Так сказать, я создаю свой собственный PropertyDescriptor через ICustomTypeDescriptor, тогда метод IsReadOnly() переопределит все атрибуты ReadOnly, которые уже были применены к нему? –

+0

Это правильно. –

3

Никакой разницы, когда я смотрю на него с помощью рефлектора.

Один из производных классов SimplePropertyDescriptor имеет следующий код.

 

    public override bool IsReadOnly 
    { 
     get 
     { 
      return this.Attributes.Contains(ReadOnlyAttribute.Yes); 
     } 
    } 
 
0

Просто примечание.

Я провел день, реализуя ICustomTypeDescriptor для объектов сущности в своем приложении, чтобы управлять состоянием, доступным только для чтения, для каждого объекта отдельно.

Таким образом, каждая реализация PropertyDescriptor хранится ссылка на объект сущности она пришла, поэтому IsReadOnly свойство было что-то вроде этого:

public override bool IsReadOnly 
{ 
    get { return _owner.IsReadOnly;} 
} 

Однако, когда я побежал код компонента BindingSource прочитал набор PropertyDescriptor s из метода GetProperties() ICustomTypeDescriptor для каждой записи в наборе, однако, когда он проверял значение IsReadOnly, он тестировал PropertyDescriptor только из первой записи.

Полная потеря времени !!!!

 Смежные вопросы

  • Нет связанных вопросов^_^