Использование пространства имен System.ComponentModel

Я считаю себя довольно опытным разработчиком .NET, но почти никогда не использовал напрямую типы в пространстве имен System.ComponentModel. (Я реализовал несколько пользовательских атрибутов и использовал их с помощью отражения).

В каких сценариях наиболее полезны такие типы, как Component, Container, PropertyDescriptor, TypeDescriptor, License и TypeConverter?

Я часто видел упоминание System.ComponentModel, когда речь шла о «дизайнерах», таких как те, что доступны в Visual Studio.

Полезны ли эти типы только тогда, когда вы, например, хотите создать настраиваемый элемент управления с красивым визуальным дизайнером (например, настраиваемые свойства и т. д.)? Или я мог бы также использовать их в более общем коде?


.net system.componentmodel
person Ash    schedule 15.12.2009    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Как и вы, я использовал перечисленные вами классы (Component, Container и т. д.) только косвенно, то есть в уже производной форме (каждый System.Windows.Forms.Control происходит от Component и т. д.). Так что мне больше нечего добавить. При добавлении свойств в пользовательские элементы управления я почти всегда использую многие классы DefaultValueAttribute, DesignerSerializationVisibilityAttribute и другие классы *Attribute. Но это довольно распространено и, вероятно, не то, о чем ваш вопрос.

Что касается остальной части пространства имен, мне нужно много асинхронной обработки, и я часто использую следующее:

  • AsyncOperation
  • Асиноператионменеджер
  • ProgressChangedEventHandler / ProgressChangedEventArgs
  • RunWorkerCompletedEventHandler / RunWorkerCompletedEventArgs
person Dave Mateer    schedule 15.12.2009
comment
Для асинхронной обработки я фактически использовал модель асинхронного программирования, т.е. делегаты и BeginInvoke(), EndInvoke(). Знаете ли вы, чем отличаются AsyncOperation и т. д.? - person Ash; 15.12.2009
comment
Когда вы создаете класс, предоставляющий асинхронные события, вы обычно используете AsyncOperation и т. д. Другими словами, когда вы являетесь поставщиком асинхронных событий, а не потребителем. Если вы создаете класс с методами DoWorkAsync() и CancelAsync() и событиями DoWorkCompleted и DoWorkProgressUpdated, вы можете использовать их, чтобы убедиться, что события вызываются в правильном потоке. - person Dave Mateer; 15.12.2009