mai
2007
Un article de Matthieu MEZIL
Imaginez le cas suivant : vous avez une classe C1, un RealProxy<C1> et une interface graphique sur laquelle vous avez des contrôles bindés avec les propriétés de C1 via le RealProxy.
Ce RealProxy est définit de tel sorte que si une exception se produit lors du set d’une propriété de C1, il remonte un évènement. Ainsi, en cas de binding, même si l’utilisateur a rentré une valeur qui génère une exception, il ne sera pas bloquer sur son contrôle. Vous pouvez vous abonnez à l’évènement et gérer un ErrorProvider par exemple afin d’avertir l’utilisateur de l’erreur.
Maintenant imaginons que C1 implémente ICustomTypeDescriptor.
Cela vous permet de vous binder sur des propriétés « virtuelles ».
Dans ce cas là, il faudra que la méthode Invoke de votre RealProxy surveille l’appel à la méthode GetPropertyOwner afin de lui renvoyer non pas C1 mais l’instance du __TransparentProxy associé à C1. Si vous ne faites pas ça, le set des propriétés (via binding) ne passera plus par le RealProxy.
Même si je n’y ai pas traité le ICustomTypeDescriptor, j’ai écrit un article sur le DataBinding avancé qui reprend en partie de ces notions.
Très intéressant, je creuserai quand j’aurai 5 mins.
Quelque chose qui n’a rien à voir mais que je trouve intéressant, c’est la validation en WPF. cf post de Thomas.
Pour la remontée d’erreur « Business » via le databinding, on dispose de l’interface IDataErrorInfo, utilisée notamment par l’ErrorProvider.
IDataErrorInfo couplé avec un framework de validation d’objets par attributs (type EntityValidator des EnterpriseLibrary 3.0) offre une souplesse du tonnerre