2009-12-15 4 views
7

Je me considère comme un développeur .NET relativement expérimenté, mais je n'ai presque jamais utilisé directement les types dans l'espace de noms System.ComponentModel. (J'ai implémenté quelques attributs personnalisés et les ai consommés via la réflexion).Utilisation de l'espace de noms System.ComponentModel

Dans quel type de scénarios les types tels que Composant, Conteneur, PropertyDescriptor, TypeDescriptor, License et TypeConverter sont-ils les plus utiles?

J'ai souvent vu System.ComponentModel mentionné lorsque je parlais de "concepteurs" tels que ceux disponibles dans Visual Studio.

Ces types sont-ils uniquement utiles lorsque vous voulez, par exemple, créer un contrôle personnalisé avec un concepteur visuel agréable (par exemple, des propriétés personnalisées, etc.)? Ou pourrais-je aussi les utiliser dans un code plus général?

Répondre

2

Comme vous, je ne l'ai utilisé les classes spécifiques que vous énumérez (Component, Container, etc.) indirectement, à savoir sous forme déjà dérivée (chaque System.Windows.Forms.Control dérive de Component, etc.). Je n'ai donc plus rien à ajouter. Lorsque j'ajoute des propriétés à des contrôles personnalisés, j'utilise presque toujours les classes DefaultValueAttribute, DesignerSerializationVisibilityAttribute et les autres classes . Mais c'est assez commun, et probablement pas ce que votre question était après.

En ce qui concerne le reste de l'espace de noms, j'ai besoin de beaucoup de traitement asynchrone, et utiliser fréquemment des éléments suivants:

  • AsyncOperation
  • AsyncOperationManager
  • ProgressChangedEventHandler/ProgressChangedEventArgs
  • RunWorkerCompletedEventHandler/RunWorkerCompletedEventArgs
+0

Pour traitement asynchrone J'ai effectivement utilisé le modèle de programmation asynchrone à savoir. délégués et BeginInvoke(), EndInvoke(). Comment AsyncOperation diffère-t-il, savez-vous? – Ash

+0

Lorsque vous créez une classe qui expose des événements asynchrones, vous utilisez généralement AsyncOperation, etc. En d'autres termes, lorsque vous êtes le fournisseur d'événements asynchrones, pas le consommateur. Si vous créez une classe avec les méthodes DoWorkAsync() et CancelAsync() et les événements DoWorkCompleted et DoWorkProgressUpdated, vous pouvez les utiliser pour vous assurer que les événements sont invoqués sur le thread approprié. –