SimonFerquel.net

[Debug] Events et MemoryLeaks

Simon FERQUEL — Fri, 30 Oct 2009 09:21:44 GMT

Une des plus grandes sources de MemoryLeaks dans les applications .Net (en particulier dans le cas d’applications Windows Forms, WPF et Silverlight), sont la création d’event handlers sur des events exposés par des objets ayant un temps de vie long, ou sur des events statiques (typiquement un évènement de la classe Microsoft.Win32.SystemEvents, ou un évènement exposé par un singleton – oui je sais, les puristes de la POO qui vont lire cette phrase vont vomir).

La raison est très simple : quand on crée un délégué (EventHandler ou autre), celui-ci possède une référence forte sur l’objet qui prend en charge l’évènement. De plus, quand on ajoute un délégué à un évènement (typiquement MonObjetSource.MonEvent += monEventHandler), cet évènement a une référence forte au délégué. Du coup, tant que l’on ne se désabonne pas, l’objet prenant en charge l’évènement reste référencé, et si la source de l’évènement n’est pas elle-même déréférencée (ce qui n’est jamais le cas avec des events statiques par exemple), l’objet prenant en charge l’évènement ne sera jamais collecté par le Garbage Collector : et on a un jouli potentiel memory leak (les puristes appellent ca plutôt un Handle Leak, parce que la source du problème n’est pas un oublie de désallocation de mémoire, mais un oublie de déréférencement).

Le cas typique, c’est un composant qui s’abonne à un évènement système, mais qui ne se désabonne jamais. Potentiellement à cause d’un oubli d’appel à une méthode Dispose ou quelque chose dans le genre. Un autre cas courrant, c’est le controlleur (ou le ViewModel) d’une vue qui s’abonne à un évènement d’un objet métier à longue durée de vie, et qui ne s’y désabonne pas (en Silverlight, c’est d’ailleurs très compliqué de se désabonner d’un évènement quand un contrôle sort de l’arbre visuel, car on n’a pas d’évènement UnLoad).

Comment faire face à ce problème (pas super simple à debugger pour courroner le tout, souvent incompris par les développeurs novices, et encore plus souvent détecté par le client qui se plaint d’une consommation mémoire désastreuse, à qui souvent les développeurs disent “ca peut pas venir de nous, nous on gère pas la mémoire, c’est le Garbage Collector qui sait”, et qui du coup s’en va propager la nouvelle comme quoi franchement, les Applis .Net c’est super lourd, faut 40 go de RAM pour les faire tourner, et au bout de 16 heures d’activité, ca fait systématiquement une OutOfMemoryException) ? Il existe plusieurs possibilités (liste pas forcément exhaustive) :

Toujours, toujours, TOUJOURS se désabonner à un évènement auquel on s’est attaché, sauf pour :
- Les évènements des contrôles si et seulement si ils sont pris en charge par le UserControl ou le formulaire qui les a créés (et qui les contient)
- Si l’objet qui prend en charge l’évènement est lui même un singleton (oui je sais les puristes, le singleton c’est pas bon)
Utiliser le WeakEventManager / WeakEvents pattern (mais c’est pas disponible sous Silverlight, et en plus c’est compliqué)
Créer un objet WeakEventHandler qui servira de proxy entre l’évènement et sa cible (l’idée est de référencer la cible uniquement via une WeakReference).

Le problème de cette dernière solution (la seule possible dans certains cas avec Silverlight), c’est que la classe WeakEventHandler est compliquée à implémenter, et peut potentiellement cacher un nouveau leak. Je vous donne donc ici, mon implémentation de référence, ainsi qu’un code snippet permettant de générer des WeakEventHandlers spécifiques à un évènement donné. L’idée étant d’avoir au final une utilisation aussi simple que :

PropertyChangedWeakEventHandler.Initialize(this, EventSource,
    (target,s, a)=>target.Messages.Add(a.PropertyName+ " changed"));

La méthode initialize prend 3 paramètres : la cible de l’évènement (qui sera encapsulée dans une WeakReference), l’objet source de l’évènement PropertyChanged, et un délégués statiques (qui n’a donc pas de référence à l’objet courrant et ne provoquera pas de leak). Ce dernier paramètre est vérifié à l’exécution en regardant si sa propriété Target est non nulle. Le délégué obtiendra une référence à l’objet cible grace à son premier paramètre.

Le code derrière cette classe est assez complexe, il repose lui même sur une classe générique abstraite que j’utilisais précédement directement, mais qui demandait un peu plus de plomberie, et était du coup beaucoup plus susceptible de provoquer des bugs.

Du coup, je vous file juste les sources contenant tout ce qu’il faut pour prendre en charge les évènements PropertyChanged, ainsi qu’un code Snippet permettant de créer vos propres WeakEventHandlers spécifiques (pour CollectionChanged, SystemEvents etc.) sans avoir à comprendre comment fonctionne la classe de base (allez, petit spoiler quand même, elle a 4 paramètres génériques, et fait largement partie des bouts de codes les moins lisibles que j’ai peu produire) : SStuff.Events.zip.

Co/Contra Variance : une nouveauté pas si nouvelle

Simon FERQUEL — Fri, 09 Oct 2009 11:03:07 GMT

C# 4.0 introduit une nouveauté très intéressante au niveau des déclarations d’interfaces / délégués génériques : la notion de Co-variance et Contra-variance.

La co-variance permet de dire que si un type implémente IMonInterface<TypeDérivé>, il implémente aussi IMonInterface<TypeParent>.

Pour la contra-variance, c’est exactement le contraire.

Du coup, les développeurs de la BCL ont modifié la déclaration de pas mal d’interfaces et délégués génériques pour profiter de ces règles : ainsi tout IEnumerable<string> implémente automatiquement IEnumerable<object> et tout délégué de type Action<object> peut être utilisé à la place d’un Action<string>.

En fait cette notion de co-variance / contra-variance, bien que non déclarable en C# et VB dans leur versions actuelle est présente dans les spécifications du langage MSIL depuis .Net 2.0, et si l’on en a le courage, on peut tout a fait créer des interfaces / délégués co/contra-variants. Pour ceci, il faut simplement indiquer un “+” (co-variant) ou un “-“ (contra-variant) devant le paramètre du type. Voici un exemple avec 2 interfaces définie en MSIL :

.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) 
  .ver 2:0:0:0
}
.assembly Cotypes
{
  .ver 0:0:0:0
}
.module Cotypes.dll


// +T indique que l'interface est CoVariante (toute implementation de IValueProvider<ChildClass>
// implemente IValueProvider<ParentClass>)
.class interface public abstract auto ansi Cotypes.IValueProvider`1<+T>
{
  .method public hidebysig newslot abstract virtual 
          instance !T  GetValue() cil managed
  {
  } 
} 

// -T indique que l'interface est ContraVariante (toute implementation de IValueConsumer<ParentClass>
// implemente IValueConsumer<ChildClass>)
.class interface public abstract auto ansi Cotypes.IValueConsumer`1<-T>
{
  .method public hidebysig newslot abstract virtual 
          instance void  SetValue(!T 'value') cil managed
  {
  } 

}

Une fois compilée sous forme de DLL, on peut alors implémenter ces interfaces en C# et profiter la co/contra-variance :

static void Main(string[] args)
{
    IValueProvider<string> stringProvider = new StringValueProvider("HelloWorld");
    IValueProvider<object> objProvider = stringProvider as IValueProvider<object>;

    IValueConsumer<object> objConsumer = new ConsoleDisplayer();
    IValueConsumer<string> stringConsumer = objConsumer as IValueConsumer<string>;

    objConsumer.SetValue(objProvider.GetValue());
    stringConsumer.SetValue(stringProvider.GetValue());
}

En C# 4.0, la seule différence (en dehors du fait que l’écriture de telles interfaces peut se faire directement en C#) est qu’il n’y a pas besoin du mot-clef as, l’opération de cast se fait implicitement.

Vous pouvez télécharger les sources de cet exemple ici.

INotifyPropertyChanged

Simon FERQUEL — Wed, 07 Oct 2009 12:58:26 GMT

Lorsque l’on développe des applications avec WPF ou Silverlight, une des tâches les plus répétitives et les plus propices aux erreurs est l’implémentation de INotifyPropertyChanged et la génération d’évènements lors de l’affectation d’une propriété sur nos objets source de DataBinding. Voici par exemple une classe Customer implémentant INotifyPropertyChanged d’une manière classique :

public class Customer : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }

    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set
        {
            if (_firstName != value)
            {
                _firstName = value;
                OnPropertyChanged("FirstName");
            }
        }
    }

    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set
        {
            if (_lastName != value)
            {
                _lastName = value;
                OnPropertyChanged("LastName");
            }
        }
    }
}

Ce code illustre très bien deux problèmes :

C’est très verbeux
Une faute de frappe dans la chaine de caractères passée à la méthode OnPropertyChanged est vite arrivée (ca m’est d’ailleurs arrivé pendant l’écriture de cet article, car je switch pas mal entre clavier Azerty et Qwerty)

Je reviendrai un peu plus tard sur le premier problème, pour l’instant nous allons nous concentrer sur le second qui est pour moi le plus critique. En plus du risque de faute de frappe, il expose aussi le développeur à des erreurs possibles lors d’un potentiel Refactoring. Pour rendre ce code plus sûr et vérifié à la compilation, il existe plusieurs alternatives :

Utiliser un composant ObservableObject (voir http://compositewpf.codeplex.com/) qui encapsule l’implémentation d’INotifyPropertyChanged via une classe séparée : cette solution est séduisante à première vue mais conduit à un nombre peu commode d’indirections lorsque l’on veut accéder à une valeur (monCustomer.FirstName=”toto” devient monCustomer.FirstName.Value = “toto”)

Utiliser la reflection pour récupérer le nom de la propriété courrante :

public class Customer : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }

    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set
        {
            if (_firstName != value)
            {
                _firstName = value;
               
                OnPropertyChanged( MethodInfo.GetCurrentMethod()
                    .Name.Substring(4));
            }
        }
    }

    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set
        {
            if (_lastName != value)
            {
                _lastName = value;
                OnPropertyChanged( MethodInfo.GetCurrentMethod()
                    .Name.Substring(4));
            }
        }
    }
}

Cette solution est originale, mais faire appel aux API d’introspection à chaque affectation de propriété a un impact très négatif sur les performances

Ma solution préférée : passer par des arbres d’expression Linq en modifiant légèrement la signature de OnPropertyChanged :

using System;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Ink;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.Linq;
using System.ComponentModel;
using System.Reflection;
using System.Linq.Expressions;

namespace SStuff.NotifySample
{
    public class Customer : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;
        protected void OnPropertyChanged<T>(Expression<Func<T>> propAccess)
        {
            if (PropertyChanged != null)
            {
                var asMember = propAccess.Body as MemberExpression;
                if (asMember == null)
                    return;

                PropertyChanged(this, new PropertyChangedEventArgs(asMember.Member.Name));
            }
        }

        private string _firstName;
        public string FirstName
        {
            get { return _firstName; }
            set
            {
                if (_firstName != value)
                {
                    _firstName = value;
                   
                    OnPropertyChanged( ()=>FirstName);
                }
            }
        }

        private string _lastName;
        public string LastName
        {
            get { return _lastName; }
            set
            {
                if (_lastName != value)
                {
                    _lastName = value;
                    OnPropertyChanged( ()=> LastName);
                }
            }
        }
    }
}

Cette solution a l’avantage d’être TypeSafe, relativement concise et plus lisible que la version basée sur la Reflection, et l’impact du parcours d’arbre d’expression sur les performances est censé être relativement réduit.

Cela dit, toutes ces solutions ont en commun le fait de ne pas résoudre mon premier problème : ce code est très verbeux. A l’occasion des derniers Mecredis du Developpement (du jeudi) j’ai imaginé une solution qui me parait bien plus élégante : depuis quelques temps j’aborde tous mes développements d’applications WPF / Silverlight en utilisant le framework d’injection de dépendances Unity. Cela me permet entre autres d’isoler mes différents ViewModel afin de pouvoir les tester unitairement, et de créer des implémentations additionnelles spécifiques au DesignTime. En combinant injection de dépendance et création de types dynamiques (en utilisant Reflection.Emit), on peut ainsi retarder l’implémentation d’INotifyPropertyChanged à l’exécution ! Avec bien sûr un surcoup au démarrage (le temps de générer l’IL correspondant aux types dynamiques) qui est compensé ensuite par des performances tout à fait satisfaisantes, et une beaucoup plus grande pureté du code :

public class Customer
{
    [Notify]
    public virtual string FirstName { get; set; }
    [Notify]
    public virtual string LastName { get; set; }
}

Pour enregistrer ensuite le type dans Unity, le code est ensuite ultra-simple (grâce aux méthodes d’extension):

container
    .RegisterType(typeof(Customer), 
                  typeof(Customer).AsNotify(null));

La méthode d’extension AsNotify génère un type hérité de Customer dynamiquement implémentant INotifyPropertyChanged correctement. Le paramètre optionel permet de fournir un MethodInfo au cas où une méthode OnPropertyChanged existerait déjà sur le type de base.

Pour créer une instance de mon Customer dynamique, je passe alors pars Unity : container.Resolve<Customer>();

Pour permettre des scénarios assez avancés avec l’injection de dépendance, tous les constructeurs de la classe de base sont reproduit dans le type dynamique, ainsi cette méthode s’intègre très bien dans une architecture MVVM avec injection de dépendances.

Le code du NotifyTypeBuilder ainsi qu’un exemple MVVM avec Unity sont récupérable ici.

Technorati Tags: WPF,Silverlight,MVVM,INotifyPropertyChanged

[Concurrency] Privatizable Shared state

Simon FERQUEL — Fri, 04 Sep 2009 08:19:20 GMT

Le titre de ce post peut paraitre un peu obscur, mais il fait référence à une technique expliquée par Joe Duffy dans son livre Concurrent Programming on Windows (pour info, le monsieur est Lead developper et architecte sur PFX, il envoit sacrément du pâté et son bouquin est un must-read absolu pour tout développeur souhaitant garder son job dans les 5 ans à venir).

Un objet privatisable répond astucieusement à la problématique bien connue dans le développement de solutions multi-thread qu’est le partage d’un état en lecture-écriture. Le partage d’état connait deux contraintes importantes :

On doit se protéger des Race-conditions (multiples load-store en parallèle)
Les modifications d’états composites doivent apparaître de manière atomique (l’objet doit apparaitre dans un état valide et cohérent à tout moment)

Une solution très simple à cette problématique est l’utilisation d’un Mutex ou Monitor (le monitor étant une version allégée du Mutex, nécessitant moins de switch user-mode / kernel-mode):

public class Exemple
{
    private MySharedState _sharedState = new MySharedState();

    public void FirstThread()
    {
        // make some long-running task

        // get the exclusive access on _sharedState
        lock (_sharedState)
        {
            // read-write access with mutual exclusion
        }
    }

    public void SecondThread()
    {
        // make some long-running task

        // get the exclusive access on _sharedState
        lock (_sharedState)
        {
            // read-write access with mutual exclusion
        }
    }
}

Cette solution bien que fonctionnelle, cette solution pose d’importants problèmes :

Si un développeur “oublie” de poser un lock lors d’une lecture-écriture, on peut se retrouver avec un bug de type Race Condition
Si un développeur ne pose pas de lock sur un bloc contenant plusieurs lectures de propriétés différentes, il y a un risque d’incohérence (un autre thread aura pu modifier l’état de l’objet entre 2 reads)
Un seul thread ne peut entrer dans le lock à un moment T, même si tous les threads concurrents n’ont besoin que d’un accès en lecture (ce qui peut poser un gros problème de performance si la majeur partie des accès se font en lecture seule).

Un objet privatisable pallie à tous ces problèmes. L’idée est que l’état partagé est accessible en lecture seule par défaut, et pour pouvoir le modifier, il faut d’abord le “privatiser” (si on essaie de modifier une propriété sans privatiser l’objet auparavant, on reçoit une exception). Privatiser un objet revient à poser un verrou exclusif en lecture-écriture sur l’objet pour le thread courant. Un seul thread peut privatiser l’objet à chaque instant, et pendant toute la durée de la privatisation, les accès à l’objet (en écriture comme en lecture) sont bloqués (grâce à un ReaderWriterLockSlim). Une fois les modifications terminées, le thread “owner” publie l’objet qui redevient accessible en lecture seule pour tout le monde jusqu’à la prochaine privatisation. De plus, plusieurs threads peuvent accéder simultanément en lecture-seule à l’objet, pour éviter des problèmes de performance.

Les lectures concurrentes ne s’entre-bloquent pas, les “états intermédiaires” ne sont visibles que par le thread responsable du changement d’état, et les développeurs n’ont pas besoin de poser un “lock” manuellement.

Bien sûr, la création d’un tel objet n’est pas forcément super simple, surtout si en plus de ca, l’objet est une source de data-binding dans un client riche (il faut alors retarder les évènements PropertyChanged / CollectionChanged afin que le thread GUI ne soit pas bloqué trop longtemps sur une ré-évaluation de propriété). J’ai donc créé 3 classes réutilisables simplement pour créer des objets privatizables :

PrivatizableObject : classe abstraite fournissant le comportement de base, implémentant INotifyPropertyChanged avec retardement, et permettant la privatisation de graphes d’objets complexes
PrivatizableList<T> : dérive de PrivatizableObject et implémentant IList<T>
PrivatizableObservableCollection<T> : dérive de PrivatizableList<T> et implémente INotifyCollectionChanged avec retardement

Pour créer un PrivatizableObject personnalisé, il suffit alors de dériver de PrivatizableObject, et d’utiliser la syntaxe suivante pour déclarer une propriété :

private class TestablePrivatizableObject : PrivatizableObject
{
    private string _testProperty;
    public string TestProperty
    {
        get
        {
            base.BeginRead();
            string value = _testProperty;
            base.EndRead();
            return value;
        }
        set
        {
            MarkPropertyChanged("TestProperty");
            _testProperty = value;
        }
    }

    public TestablePrivatizableObject(bool privatize) 
        : base(privatize)
    { }

    public TestablePrivatizableObject(PrivatizableObject privatizationController)
        : base(privatizationController) { }
}

Comme vous pouvez le voir, l’implémentation n’a plus grand chose de compliqué !

A l’utilisation, là aussi rien de bien méchant :

Accéder à une propriété :

string value = myObject.TestProperty;

Modifier l’état partagé:

using (myObject.Privatize())
{
    myObject.TestProperty = "test";
    myObject.TestProperty2 = "test2"; 
} // a la fin du bloc, l’objet est automatiquement publié

Effectuer une série de “reads” atomique :

using (testee.CreateReadRegion())
{
    value1 = myObject.TestProperty;
    value2 = myObject.TestProperty2;
}

Cette solution, bien que fournie avec une batterie de tests unitaires, est fournie “as-is”, mais est totalement libre de droits :

Téléchargez la solution

[Perso] Bybye Winwise

Simon FERQUEL — Wed, 02 Sep 2009 09:31:34 GMT

Avant-hier vient de s’achever une page de ma vie professionnelle importante : mon job (chez Winwise) vient de se terminer. J’ai donc désormais pas mal de temps libre, et quelques articles techniques ne devraient pas tarder à voir le jour sur ce blog (notamment des choses autour du développement parallèle, et sûrement une série sur DirectX 10, maintenant que j’ai montré comment faire interagir WPF avec cette technologie).

Je profite aussi de ce post pour vous rappeler que mes bons services sont à louer… Donc si vous avec des besoins particuliers en conseil ou développement custom autour des technologies .Net (et plus particulièrement C# 3.0 / Linq, WPF, Silverlight, WCF, Visual Studio SDK, DirectX, C++ / CLI ou développement parallèle), n’hésitez pas à me contacter via ce blog.

[WPF / DirectX] Interopérabilité WPF / DirectX 10

Simon FERQUEL — Fri, 24 Jul 2009 16:54:57 GMT

Depuis la version 3.5 SP1 du Framework .Net, il est possible en WPF de consommer une surface rendue à l’aide de DirectX 9 (grâce à XNA, Managed DirectX ou en C++ / CLI). Malheureusement, de base, WPF ne supporte pas les textures produites par DirectX 10. D’autres solutions existent, comme par exemple l’utilisation de SlimDX, mais jusqu’à maintenant, elles passaient toutes par de l’interopérabilité Win32, et ne permettaient donc pas d’intégrer le contenu DX10 au moteur d’animations / transformations de WPF.

Le but de cet article est de montrer une technique permettant sous Windows VISTA, 7 et à priori supérieur d’injecter une surface rendue en DirectX 10 dans le moteur de composition de WPF.

Un nain rendu en DirectX10 / HLSL4 et mélangé à du contenu WPF

Le principe

Le principe est d’exploiter les fonctionnalités apportées par Windows VISTA et son système WDDM (Windows Display Driver Model) à DirectX 9 et plus particulièrement le système de partage de ressources, qui permet de partager des objets en mémoire sur le GPU entre plusieurs devices DirectX. On va donc créer à partir d’un Device DirectX 9 Ex (DirectX 9 Ex est la version de DirectX9 adaptée au WDDM de VISTA / 7) une texture que l’on va partager avec un Device DirectX10, effectuer un rendu dedans à l’aide de DirectX 10, et la présenter à WPF grâce à DirectX 9. Les performances sont assurées grâce au fait que le partage de ressources tel qu’implémenté dans Windows VISTA / 7 n’implique pas de recopie en mémoire système : la texture ne quitte jamais la mémoire de la carte graphique, de son rendu en DirectX10 jusqu’à son exploitation par le moteur de composition de WPF (basé lui-même sur DirectX 9 Ex).

Les obstacles

L’obstacle le plus gênant a été de trouver de la documentation sur le Resource Sharing entre DirectX 9 et DirectX 10. Il y’a effectivement pas mal de contraintes, et les formats de textures supportés à la fois par DirectX9 et DirectX 10 ne sont pas légions… Et aucun d’entre eux n’est compatible avec WPF !

Il a donc fallu passer par une technique de conversion bien connue des développeurs Direct3D (et dont les performances sont impressionnantes par rapport à ce qu’on obtiendrait en faisant ca sur le CPU) baptisée empiriquement la technique des 2 gros triangles. Il s’agit simplement de créer une texture DirectX 9 compatible WPF, et d’effectuer dedans le rendu de 2 polygones recouvrant l’intégralité du ViewPort, auxquels on applique la texture non supportée (pour des performances optimales, on désactive le plus de traitements possibles, notamment la rastérisation, l’éclairage, le Z-Buffer…).

La réalisation

La réalisation ensuite est relativement simple (pour peu que l’on connaisse un minimum WPF, C++ / CLI et les API DirectX).

On se retrouve effectivement avec une classe C++ Native dont le but est de créer les Devices DirectX 9 EX et DirectX 10, leurs ressources associées et d’effectuer le rendu, une classe C++ / CLI servant de proxy à la classe de rendu, et un contrôle WPF récupérant le handle de surface DirectX 9 Ex et l’affichant grâce au composant D3DImage (faites une recherche sur votre moteur de recherche préféré sur D3DImage, y’a pas mal de documentation sur le sujet). Dans l’exemple illustrant cet article, le composant WPF envoie les paramètres de rendu à la classe proxy qui appelle la classe de rendu qui charge alors les fichiers de modèles, les shaders et quelques paramètres associés.

Voici quelques morceaux de choix du code de l’exemple :

Création des textures DirectX 9 (NativeRenderer.cpp) :

// Creating DX9 textures 

HRESULT hr = m_deviceEx->CreateTexture(width,
    height,
    1,
    D3DUSAGE_RENDERTARGET,
    D3DFMT_A16B16G16R16F, // Required for DirectX10 Interop
    // but does not work with WPF D3DImage. So we need to copy into an other 
    // D3D9 texture with correct WPF format. For this we simply render a rectangle
    D3DPOOL_DEFAULT, 
    &m_renderTexture,
    &shareHandle);
assert(SUCCEEDED(hr));

// This texture will be passed to WPF D3DImage
hr = m_deviceEx->CreateTexture(width,
    height,
    1,
    D3DUSAGE_RENDERTARGET,
    D3DFMT_A8R8G8B8,
    D3DPOOL_DEFAULT,
    &m_renderTextureCopy,
    NULL);
assert(SUCCEEDED(hr));

Ouverture de la texture partagée par le device DirectX 10

// Now we open the shared texture from the DX10 Device
ID3D10Resource * pTempResource;
hr = m_device10->OpenSharedResource(shareHandle, __uuidof(ID3D10Resource), (void**)&pTempResource);
assert(SUCCEEDED(hr));
hr = pTempResource->QueryInterface(__uuidof(ID3D10Texture2D), (void**)&m_renderTexture10);
assert(SUCCEEDED(hr));
SAFE_RELEASE(pTempResource);

// And we create a Render Target View from it
hr = m_device10->CreateRenderTargetView(m_renderTexture10, NULL, &m_rtv);
assert(SUCCEEDED(hr));

Configuration du pipeline DX9 pour la conversion de texture à l’aide des 2 gros triangles

// The texture in which DX10 content is drawn is set as an input Texture
// in the DX9 device
hr = m_deviceEx->SetTexture(0, m_renderTexture);
assert(SUCCEEDED(hr));


// And the output is set to the texture which has a WPF compatible format
hr = m_renderTextureCopy->GetSurfaceLevel(0, &m_renderTarget);
assert(SUCCEEDED(hr));

hr = m_deviceEx->SetRenderTarget(0, m_renderTarget);
assert(SUCCEEDED(hr));

// This is the rectangle that will be used for the texture conversion 
// rendering pass
m_quad[0].x = 0;
m_quad[0].y = 0;
m_quad[0].z = 0.5;
m_quad[0].rhw = 1.0;
m_quad[0].u = 0;
m_quad[0].v = 0;

m_quad[1].x = (float)width;
m_quad[1].y = 0;
m_quad[1].z = 0.5;
m_quad[1].rhw = 1.0;
m_quad[1].u = 1;
m_quad[1].v = 0;

m_quad[2].x = 0;
m_quad[2].y = (float)height;
m_quad[2].z = 0.5;
m_quad[2].rhw = 1.0;
m_quad[2].u = 0;
m_quad[2].v = 1;

m_quad[3].x = (float)width;
m_quad[3].y = (float)height;
m_quad[3].z = 0.5;
m_quad[3].rhw = 1.0;
m_quad[3].u = 1;
m_quad[3].v = 1;

IDirect3DVertexBuffer9* vertBuffer;
hr = m_deviceEx->CreateVertexBuffer(4*sizeof(QuadVertex), 
         D3DUSAGE_WRITEONLY, 
         QUAD_FORMAT, 
         D3DPOOL_DEFAULT, &vertBuffer,NULL);
assert(SUCCEEDED(hr));
void* bufferData = NULL;
hr = vertBuffer->Lock(0,0, &bufferData, 0);
memcpy(bufferData, (void*)m_quad, 4*sizeof(QuadVertex));
vertBuffer->Unlock();

hr = m_deviceEx->SetStreamSource(0, vertBuffer, 0, sizeof(QuadVertex));
assert(SUCCEEDED(hr));
SAFE_RELEASE(vertBuffer);

Rendu (effectué sur l’évènement Rendering du CompositionTarget) :

HRESULT hr;

if(m_rtv == NULL)
    return;

// Send the transformation matrices to the GPU
ApplyMatrices();

// Update the BumpForce shader variable
m_fBumpForceVariable->SetFloat(m_bumpForce);

// Update the fTime shader variable
float time = (float)m_stopWatch.GetElapsedSeconds();
m_fTimeVariable->SetFloat(time);

// Clear the Depth Buffer
m_device10->ClearDepthStencilView(m_dsv, D3D10_CLEAR_DEPTH, 1.0,0);

// Clear the render target
float clearColor[] = {0.0,0.0,0.0,.0};
m_device10->ClearRenderTargetView(m_rtv, clearColor);    

// Render the mesh
if(m_meshManager != NULL)
{
    ID3DX10Mesh *mesh = m_meshManager->GetMesh();
    
    ID3D10InputLayout * inputLayout = m_meshManager->GetInputLayout();
    m_device10->IASetInputLayout(inputLayout);

    DWORD partCount = m_meshManager->GetMaterialCount();
    D3D10_TECHNIQUE_DESC td;

    for(DWORD i = 0;i<partCount;i++)
    {
        const MATERIAL10* mat = m_meshManager->GetMaterial(i);
        m_txDiffuseVariable->SetResource(mat->diffuseMap);
        m_txBumpVariable->SetResource(mat->bumpMap);
        m_renderTechnique->GetDesc(&td);
        m_hasEffect9Variable->SetBool((BOOL)mat->hasEffect9 && m_activateSpecularLighting);
        for (DWORD p = 0; p < td.Passes;p++)
        {
            ID3D10EffectPass *pass = m_renderTechnique->GetPassByIndex(p);
            pass->Apply(0);
            HRESULT hr;
            hr = mesh->DrawSubset(i);
            
            assert(SUCCEEDED(hr));
        }
    }
}

// Flush the generated content
m_device10->Flush();



// Begin the DX9 pass
m_deviceEx->BeginScene();

// Clear the WPF Render Target
hr = m_deviceEx->Clear(0,NULL,D3DCLEAR_TARGET, D3DCOLOR_ARGB(0,0,0,0), 1.0,0);

// Draw the 2 big triangles
hr = m_deviceEx->DrawPrimitive(D3DPT_TRIANGLESTRIP, 0, 2);

// End the DX9 pass
m_deviceEx->EndScene();
hr = m_deviceEx->Present(NULL,NULL,NULL,NULL);

Si ce code ne vous fait pas peur, à priori je n’ai pas besoin de vous mettre en évidence le code de la classe proxy ni celle du contrôle WPF. Vous pouvez retrouver l’intégralité du code (et des assets graphiques tirés des samples du SDK DirectX) ici.

Les pré-requis sont :

VS 2008 SP1 (avec support de C# et C++)
Windows Vista ou 7
Une carte 3D DirectX 10
Le SDK DirectX de mars 2009
Les C++ Directories bien configurés dans Visual Studio pour pouvoir accéder aux includes / libs du sdk DirectX

Conclusion

Cette technique ouvre la porte à de nouveaux scénarios d’intéraction avec du contenu DirectX. On peut imaginer des outils de production 3D, des gestionnaires d’assets pour des éditeurs de jeu vidéo, des environements de développement de hlsl, des interfaces de simulation en 3D… Le tout en obtenant à la fois les avantages de la productivité apportée par WPF, et les performances et les possibilités en terme de rendu 3D de DirectX 10 (et apriori, la même chose sera possible avec DirectX 11 !)

[.Net 4.0] Parallel Task Library

Simon FERQUEL — Tue, 02 Jun 2009 08:18:38 GMT

La beta 1 de Visual Studio 2010 et du Framework .Net 4.0 est disponible depuis quelques jours (normalement, si vous lisez ce blog, vous êtes déjà au courrant !), et une des nouveautés majeures de cette nouvelle version (si ce n’est LA nouveauté) concerne le Multi-Threading. En effet, .Net 4.0 intègre un certain nombre d’améliorations au niveau du ThreadPool qui ont permis de créer tout un jeu d’APIs dédiées à l’exécution de tâches en parrallèle et à leur synchronisation.

Ces APIs se distinguent en 3 catégories :

Task & TaskScheduler : Il s’agit de la possibilité de créer des tâches avec une granularité très fine, de définir des dépendances (telle tâche ne peut démarrer avant la fin de l’exécution de telle autre), et de les exécuter. Le TaskScheduler se chargera alors de distribuer ces tâches entre les différents Threads du ThreadPool pour exploiter au mieux les ressources de la machine. On peut aussi utiliser les tâches pour effectuer des traitements asynchrones afin de ne pas bloquer un Thread de rendu en WPF ou Windows Forms par exemple.
Parallel loops : Il s’agit d’un ensemble de méthodes statiques remplacant les boucles traditionelles, permettant de traiter chaque itération d’une boucle for / foreach dans des tâches séparées afin de parallèliser le traitement, et potentiellement d’aggréger les résultats des traitements de chaque tour de boucle. Parallel.For, Parallel.Foreach, Parallel.Do etc. reposent sur les classes Task et TaskScheduler.
Parallel Linq : Il s’agit d’une extension à Linq to Objects permettant de paralleliser le traitement d’une requête. Si vous aimé tout comme moi le style de développement fonctionnel apporté par C# 3.0 et que vous mettez des lambdas, et des appels à Enumerable.Where, Enumerable.Select, etc. partout dans votre code, vous adorerez PLinq :).

L’exemple qui vient avec cet article exploite essentiellement les parallel loops. Le but de l’application est d’effectuer des traitements sur une série d’images (ajustement de contraste). L’algorythme employé n’est pas le plus optimisé qui soit, le but étant de mettre en valeur la simplicité des APIs plutôt que de concurrencer Photoshop. L’exemple a aussi l’avantage de montrer quelques astuces spécifiques au développement multi-thread avec WPF.

Focus 1 : chargement des images

La première utilisation que je fais de PTL, est assez classique, et équivaut à l’utilisation d’un BackgroundWorker. Il s’agit simplement de charger les images dans un thread séparé pour éviter de bloquer le thread UI de WPF :

if (ofd.ShowDialog() ?? false)
{
    _images.Clear();
    Task.Factory.StartNew(() =>
        {
            foreach (var file in ofd.FileNames)
            {
                try
                {
                    var source = new BitmapImage(new Uri(file));
                    source.Freeze();
                    var tuple = new SourceAndTarget { Source = source };
                    Dispatcher.BeginInvoke((Action)(() =>
                        {
                            _images.Add(tuple);
                            tuple.Target = new WriteableBitmap(source);
                        }));
                }
                catch
                {
                    MessageBox.Show("Image " + file + " failed");
                }
            }
        }).ContinueWith((t) =>
            Dispatcher.BeginInvoke((Action)(() => LoadingImages = false)));
}

Task.Factory.StartNew permet de créer une tâche à partir d’un délégué (ici une lambda) et de la scheduler. Notez la ligne source.Freeze(), elle est très importantes. En effet, avec WPF, tout DependencyObject ne peut par défaut être manipulé que dans le thread où il a été créé. Hors, comme on est dans un thread différent du Thread UI, la BitmapImage que l’on vient de créer ne peut pas, par défaut être accessible par le Thread UI.

Il existe dans WPF une classe dérivant de DependencyObject appelée Freezable permettant de “figer” l’objet et le rendre immutable. Une fois que l’objet est figé, il n’y a plus de risques liés à la concurrence d’accès (car tout accès en écriture aux propriétés est désactivé), l’objet devient accessible depuis n’importe quel thread. Beaucoup d’objets (notament les images, les brushes, les Paths etc) de WPF héritent de cette classe Freezable. Une fois notre BitmapImage crée, nous appelons donc sa méthode Freeze() pour la rendre accessible au thread UI de WPF.

Le cas de la WriteableBitmap est plus complexe, car elle demande d’être accessible par le thread UI tout en restant modifiable. Grace au Dispatcher, nous basculons donc dans le Thread UI et créons la WriteableBitmap depuis celui-ci.

Focus 2 : traitement en parallèle avec Parallel.For

Le traitement d’image se prête assez facilement à la parallèlisation. En effet, il suffit de découper l’image source, calculer les différentes portions dans des threads séparés et recomposer l’image destination. La classe ImageProcessor fournie dans l’exemple illustre cela parfaitement : que l’on passe en parallèle ou que l’on reste en traitement séquenciel, la grosse majorité du code reste identique. Seulement dans un cas, on parallèlise la boucle de traitement :

public void ProcessSequential(WriteableBitmap target, ITransformer transformation)
{
    Contract.Requires(target != null);
    Contract.Requires(transformation != null);
    int count = Math.Min(Environment.ProcessorCount * 2, _image.PixelWidth);
    int chunkWidth = _image.PixelWidth / count;

    for (int i = 0; i < count; i++)
    {
        ProcessChunck(target, transformation, count, chunkWidth, i);
    }
}

public void ProcessParallel(WriteableBitmap target, ITransformer transformation)
{
    Contract.Requires(target != null);
    Contract.Requires(transformation != null);
    int count = Math.Min(Environment.ProcessorCount * 2, _image.PixelWidth);
    int chunkWidth = _image.PixelWidth / count;

    Parallel.For(0, count, (i) =>
    {
        ProcessChunck(target, transformation, count, chunkWidth, i);
    });
    
}

Le nombre de “morceaux” d’image générés est lié au nombre de processeurs. Le *2 est simplement là pour augmenter la granularité car on ne sait pas si l’algorythme de transformation prendra autant de temps pour chaque morceau d’image. Le contenu de la méthode ProcessChunk n’est quand à lui pas très compliqué. Il s’agit simplement de récupérer les données de l’image source correspondant au morceau à traiter, de le traiter, et de l’injecter dans la WritableBitmap. On aura d’ailleurs besoin de se replacer dans le Thread UI pour effectuer cette dernière opération (la seule à ne pas être parallèlisée) :

private void ProcessChunck(WriteableBitmap target, ITransformer transformation, int count, int chunkWidth, int i)
{
    var width = chunkWidth;
    if (i == count - 1)
        width += _image.PixelWidth % chunkWidth;

    var rect = new Int32Rect(i * chunkWidth, 0, width, _image.PixelHeight);
    int stride = width * 4;
    byte[] data = new byte[stride * _image.PixelHeight];
    _image.CopyPixels(rect, data, stride, 0);
    var transformed = transformation.Transform(new ImageChunk(rect, data));
    target.Dispatcher.BeginInvoke((Action)(() =>
    {
        target.WritePixels(transformed.Rect, transformed.Data, stride, 0);
    }));
}

Conclusion

Parallel Task Library apporte une réelle facilité de syntaxe pour le développement d’applications faisant appel au parallèlisme (que ce soit pour effectuer un traitement asynchrone ou pour exploiter la puissance d’un processeur multi-coeur). En plus de cela, Visual Studio 2010 apporte une collection d’outils permettant de faciliter le Debugging d’applications multi-thread, ainsi qu’un outil de profiling permettant de détecter les problèmes rencontrés dans ces applications (contentions, attente sur une ressource partagées…).

Ce qu’il ne faut par contre pas oublier, c’est que quelque soit la technologie employée (PTL, OpenMP, etc…), il ne s’agit que d’outils simplifiant les aspects technique de la création d’applications Multi-Thread. En effet, PTL ne dispense pas le développeur de “penser” ses algorythmes dans un style parallèle (découpage en tâches, détection des tâches non-dépendantes, utilisation d’objets immutables, éviter les partages d’états…). Il faudra donc de toute façon se méfier des Race conditions, des deadlocks, etc. Le style de programmation fonctionnel apporté par C# 3.0 se prète par contre très bien à la parallèlisation, car il pousse à l’utilisation d’objets immutables et donc évite le problème le plus courrant lors du développement parallèle : le partage d’état.

Sources de la solution : ici.

Mots clés Technorati : .Net 4.0,WPF,Parallel

[Silverlight 3] Paging with RIA controls + M-V-VM without DomainDataSource

Simon FERQUEL — Tue, 12 May 2009 17:02:57 GMT

I think this topic is quite important and quite unanswered even on English-speaking blogs, so I decided to publish this entry in english… sorry French frogs!

So, a couple of weeks ago, Nikhil Kothari has written a very interesting blog post about encapsulating a RIA Services DomainContext into a ViewModel. The only feature that were not covered by the blog post was server-side paging and sorting without exposing the DomainContext and without using a DomainDataSource.

DomainDataSource is a control that encapsulate a DomainContext to provide an ICollectionView and IPagedCollectionView implementation which will be used by the RIA controls (DataGrid, DataPager…). This implementation does trigger a roundtrip to the server when the user ask for a sort or paging operation (using DataGrid headers, or DataPager control).

In a comment of his blog, Nikhil exposed a very interesting idea to make server-side paging / sorting work with a ViewModel : Implement a control similar to the DomainDataSource, but encapsulating a custom ViewModel. I have been thinking about this for a couple of days, and I implemented something that does that using reflection.

Here is the usage :

<SStuff_Ria:PagingObjectProvider x:Name="pagingObjectProvider" 
                                 DataSource="{Binding Mode=OneWay}" 
                                 GoToPageMethodName="LoadProductsPage" 
                                 ItemsSourcePropertyName="Products" 
                                 PageChangingPropertyName="PageChanging" 
                                 PageIndexPropertyName="PageIndex" 
                                 TotalItemCountPropertyName="TotalItemCount" />

(of course, the DataContext is an instance of my ViewModel, which exposes the specified methods and properties, and implements INotifyPropertyChanged).

After that, we can reference this DataSource as we did with the DomainDataSource:

<data:DataGrid Grid.Row="1"
              IsReadOnly="True"
              ItemsSource="{Binding ElementName=pagingObjectProvider,Path=Data}"
              AutoGenerateColumns="False">
    <data:DataGrid.Columns>
        …
    </data:DataGrid.Columns>
</data:DataGrid>

<dataControls:DataPager Grid.Row="2" 
                        Source="{Binding ElementName=pagingObjectProvider, Path=Data}"/>

One really cool side effect, is that the PagingObjectProvider does not depends on RIA Services at all and could be used with custom WCF Services or with ADO.Net Data Service. So we will be able to use it as soon as SL3 is out (no need to wait for a RIA Services RTW).

Here are the sources (with 2 samples : One with RIA Services and one with custom WCF Service) : SStuff.RIA.zip

[Silverlight] Silverlight 3 + RIA Services + MVVM et testabilité

Simon FERQUEL — Wed, 25 Mar 2009 16:46:00 GMT

Téléchargez la solution

Microsoft a récemment publié la Beta 1 de Silverlight 3 ainsi qu’une CTP des .Net RIA Services. Je commencerai d’ailleurs par rappeler que si Silverlight 3 RTW est prévu pour l’été prochain, les RIA Services n’ont pour l’instant aucune date de sortie, et sont sujet à des Breaking Changes TRES conséquents (les plans sont d’en faire une sorte d’extension à ADO.Net Data Services).

Toujours est-il que le modèle est très intéressant et que dès aujourd’hui, nous pouvons commencer à travailler sur l’intégration du DomainContext ainsi que des nouveautés propre à Silverlight 3 avec les Design Pattern existants actuellement pour la création d’application LOB (Line of business) avec Silverlight. Aujourd’hui je vais donc présenter quelques “early”-astuces avec Silverlight 3, RIA Services, Unity Application bloc et le pattern MVVM.

Introduction

L’application présentée est très simple : Il s’agit simplement d’une grille de données affichant une liste de personnes avec leur manager avec pour chaque ligne un bouton “Foo”, qui lorsqu’il est cliqué fait apparaitre une MessageBox contenant le nom de la personne :

Les données sont exposées par le serveur via RIA Services. Pour des raisons de simplicité, il n’y a pas de base de donnée, seulement quelques instances en mémoire.

Afin de pouvoir utiliser le pattern MVVM, il m’a aussi fallu implémenter l’interface ICommand ainsi que créer un modèle d’adapters capable d’associer une commande à un contrôle. Je ne détaillerai pas ce code, car il n’est pas du tout spécifique à Silverlight 3, et si vous travaillez en mode MVVM avec Silverlight, vous avez déjà très certainement ce qu’il vous faut pour associer des commandes à des boutons de manière déclarative.

Rappel sur M-V-VM

M-V-VM représente un modèle à 3 responsabilités :

Le modèle : Il s’agit de la business logique de l’application cliente, qui doit être indépendante de la technologie d’affichage. En général dans une application Silverlight, il s’agit de business entities échangées avec le serveur + logique de validation côté client + business logique côté client + proxy WCF. Dans notre cas, vu le peu de complexité il s’agit essentiellement du DomainContext RIA Services
La vue : En Silverlight il s’agira d’un UserControl, ou d’une page (depuis Silverlight 3), avec peu (dans l’idéal pas) de code behind.
Le ViewModel : littéralement le “modèle de la vue”. Il s’agit d’une classe encapsulant le modèle de manière à le présenter à la vue de la manière la plus “bindable” possible. Le ViewModel expose dans certain cas directement des entités du modèle, dans d’autres il les encapsule pour les rendre plus “Silverlight-aware” (par exemple en présentant les propriétés booléennes sous forme de Visibility, en fournissant les ItemsSource des combobox / listbox etc, et en présentant les comportements sous forme de Commandes sur lesquelles la vue peut se “binder”).

Un des enjeux majeurs est de faire en sorte d’avoir des vues en pur XAML, et des ViewModels complètement indépendants des vues qui leur seront associées, afin d’avoir un XAML entièrement modifiable par un designer sans que le comportement ne soit affecté.

Un autre enjeu est la testabilité des applications, et l’isolation des différents composants. Dans notre exemple, toutes les interdépendances seront résolues par injection de dépendance, à l’aide de Unity Application bloc

Introduction à l’injection de dépendance avec Unity

Le but de l’injection de dépendance est de réduire le couplage entre les différents composants d’une application. Ce pattern repose sur un composant central, le conteneur, qui permet de configurer la façon dont les différents composants seront résolus. Voici quelques exemples d’enregistrements de dépendances avec Unity:

            IUnityContainer container = new UnityContainer();
            
            // Map l'interface IMainViewModel à l'implémentation MainViewModel.
            // Chaque fois que l'on demandera un IMainViewModel à Unity, il créera une instance
            // de MainViewModel :
            container.RegisterType<IMainViewModel, MainViewModel>();
            
            // La même chose en mode "Singleton" (une seule instance sera créée
            // par le conteneur, qui sera renvoyé à chaque fois :
            container.RegisterType<IMainViewModel, MainViewModel>(new ContainerControlledLifetimeManager());

            // La même chose avec "une instance par thread" :
            container.RegisterType<IMainViewModel, MainViewModel>(new PerThreadLifetimeManager());

            // Spécifie comment notre DomainContext doit être construit
            // (ici en spécifiant un DomainClient de test plutot que le client Rest/HTTP):
            container.RegisterType<PeopleContext, PeopleContext>(new InjectionConstructor(new TestDomainClient()));

Ensuite pour résoudre une dépendance on a juste à faire :

var viewModel = container.Resolve<IMainViewModel>();

Le fonctionnement basique de Unity est vraiment très simple. Il y’a pas mal d’autres fonctionnalités comme l’injection de propriétés, l’interception d’appels de méthode (DynamicProxy…) mais elles ne seront pas présentées dans cet article

Configuration de l’application

Dans cette application, nous n’avons qu’un seul ViewModel : MainViewModel. Ce ViewModel implémente IMainViewModel :

namespace SilverlightSample.ViewModels
{
    /// <summary>
    /// ViewModel exposing data and commands
    /// </summary>
    public interface IMainViewModel
    {
        /// <summary>
        /// The RIA Services exposed Data
        /// </summary>
        PeopleContext DomainContext { get; }

        /// <summary>
        /// A command that needs a Person instance as a parameter
        /// </summary>
        ICommand FooCommand { get; }
    }
}

L’implémentation de IMainViewModel expose le DomainContext RIA afin de fournir à la vue la possibilité de définir des DomainDataSources permettant aux contrôles DataGrid et DataPager de fonctionner correctement. On expose aussi une commande à laquelle la vue pourra se binder (voir les boutons Foo dans le screenshot en début de post). Le DomainContext sera résolu par Unity, tandis qu’une RelayCommand sera créée pour la propriété FooCommand :

public class MainViewModel : IMainViewModel, IInitialize
    {
        private PeopleContext _domainContext;
        private RelayCommand _fooCommand;
        IUnityContainer _unityContainer;
        public MainViewModel(IUnityContainer unityContainer)
        {
            _unityContainer = unityContainer;

            _domainContext = unityContainer.Resolve<PeopleContext>();
          

            _fooCommand = new RelayCommand(
                obj => DoFoo(obj as Person),
                obj => obj is Person);
        }
…
}

note : MainViewModel implémente aussi IInitialize. Cette interface est déclarée dans ma boîte à outils MVVM et est utilisée par le contrôle ViewModelHelper décrit un peu plus loin.

Au niveau du App.xaml, nous allons donc configurer notre conteneur de dépendances pour IMainViewModel et PeopleContext :

private void Application_Startup(object sender, StartupEventArgs e)
{
    IUnityContainer rootApplicationContainer = new UnityContainer();
    rootApplicationContainer.RegisterType<IMainViewModel, MainViewModel>(new ContainerControlledLifetimeManager());
    rootApplicationContainer.RegisterType<PeopleContext, PeopleContext>(new InjectionConstructor()); 
//on spécifie explicitement
// l’utilisation du constructeur par défaut
    Resources.Add("RootContainer", rootApplicationContainer);

    this.RootVisual = new MainPage();
}

note : vous pouvez constater que l’on rajoute le conteneur aux ressources de l’Application afin de pouvoir y accéder de partout (y compris à partir du Xaml en utilisant une {StaticResource}).

Accéder au conteneur Unity depuis la vue

Afin d’accéder au ViewModel via Unity à partir de ma vue, j’ai créé un contrôle ViewModelHelper. Ce contrôle n’a pas de template d’affichage et permet simple d’accéder à un ViewModel enregistré dans un conteneur Unity (un peu à la manière du DomainDataSource qui permet d’accèder aux entités d’un DomainContext).

ViewModelHelper a les propriétés suivantes :

UnityContainer : le conteneur Unity utilisé pour résoudre le ViewModel
ViewModelType : le type du ViewModel (par exemple : “SilverlightSample.ViewModels.IMainViewModel, SilverlightSample, Version=1.0.0.0”)
ViewModelName (optionnel) : utilisé si l’enregistrement de la dépendance est nommé (paramètre optionnel de UnityContainer.RegisterType() et UnityContainer.Resolve())
InitParam (optionnel) : paramètre à passer à la méthode Initialize si le ViewModel implémente IInitialize.
ViewModel (lecture seule) : le ViewModel résolu

Dans notre exemple, la vue principale de l’application possède donc un ViewModelHelper :

<sstuff:ViewModelHelper 
    UnityContainer="{StaticResource RootContainer}"
    ViewModelType="SilverlightSample.ViewModels.IMainViewModel,
                   SilverlightSample, Version=1.0.0.0"
    x:Name="vmh" />

Comme Silverlight 3 introduit le Binding inter-contrôles, on peut alors se Binder au ViewModel ainsi exposé :

<ria:DomainDataSource x:Name="dds"
                              AutoLoad="True"                           
                              LoadMethodName="LoadAllPeople"
                              DomainContext="{Binding ViewModel.DomainContext, ElementName=vmh}"
                              />

Comme la vue n’est pas liée à une implémentation particulière de IMainViewModel, on peut tout à fait imaginer créer des tests unitaires vérifiant par exemple la validité des bindings, en proposant un “mock” du ViewModel en lieu et place de l’implémentation normale (c’est d’ailleurs le cas dans la solution liée au post).

note : Pourquoi ViewModelHelper est un contrôle ? Tout simplement pour pouvoir Binder son InitParam ou son ViewModelName à une propriété du DataContext (ce qui est très utile dans des scénarii de vues Master / Details où chaque vue détail est associé à un ViewModel).

Accéder au ViewModelHelper à partir d’une ligne du DataGrid

Une des limites du Binding inter-éléments de Silverlight, est qu’il ne remonte pas au NameScope parent si il ne trouve pas l’UIElement dans le scope courrant. Hors, dans mon cas, la colonne de commande est réalisée grâce à une DataGridTemplatedColumn, basé sur un template qui génèrera donc pour chaque cellule un NameScope différent. Pour palier à ce problème, j’ai écrit un deuxième contrôle non-graphique utilisé simplement pour explorer l’arbre visuel : le VisualTreeDataSource.

Ce contrôle expose 2 propriétés :

Query : n’importe quel objet implémentant IVisualTreeQuery (cette interface est vraiment très simple à implémenter, regardez les sources pour vous en convaincre)
Match (lecture seule) : contrôle retourné par la requète. Cette propriété est maintenue à jour à chaque évènement LayoutUpdated

Voici donc le template utilisé pour la colonne de commandes :

<DataTemplate>
    <Grid>
        <!-- Element Binding do not work accross NameScopes.
        RelativeSource markup extension is lacking the FindAncestor mode-->
        <!-- So, the VisualTreeDataSource is used to find an element using VisualTree browsing-->
        <sstuff:VisualTreeDataSource x:Name="vds">
            <sstuff:VisualTreeDataSource.Query>
                <sstuff:ComposedVisualQuery>
                    <!-- first get the MainPage control-->
                    <sstuff:FindAncestor AncestorType="SilverlightSample.MainPage,
                                                       SilverlightSample,Version=1.0.0.0" />
                    <!-- then find the control named "vmh"-->
                    <sstuff:FindName TargetName="vmh" />
                </sstuff:ComposedVisualQuery>
            </sstuff:VisualTreeDataSource.Query>
        </sstuff:VisualTreeDataSource>
        <!-- Now we can access the ViewModelHelper via the Match DependencyProperty 
        of the VisualTreeDataSource and bind to exposed command-->
        <Button sstuff:Commanding.Command="{Binding Match.ViewModel.FooCommand, ElementName=vds}"
                sstuff:Commanding.CommandParameter="{Binding}" 
                Content="Foo"/>
    </Grid>
</DataTemplate>

Et voilà, nous avons une vue qui accède à son ViewModel via Unity et qui n’a aucun CodeBehind.

Conclusion

Voici les différents points que j’ai abordé dans ce post :

Intégrer les RIA Services au pattern MVVM (dans ma wish-list, j’aimerais bien pouvoir me passer du DomainDataSource dans les vues tout en gardant la possibilité de tri / pagination côté server et donc ne plus être obligé d’exposé le DomainContext complet, qui n’est pas très simple à mocker)
Utiliser les nouvelles fonctionnalités de Binding de Silverlight 3 pour créer des vues “CodeBehind-less”
Réduire le couplage entre la vue et le ViewModel, et entre le ViewModel et le modèle afin d’améliorer la testabilité des composants de façon unitaire (Injection de dépendance avec Unity)
Accéder au conteneur Unity en pur Xaml pour la résolution des ViewModels

Ce que je n’ai pas abordé dans le post mais que vous pouvez trouver dans la solution téléchargeable : l’écriture des tests unitaires de la vue (par mocking du ViewModel) et du ViewModel (par mocking du DomainClient utilisé par le PeopleContext).

Téléchargez la solution

[Silverlight] AutoCompleteBox et Binding sur SelectedItem

Simon FERQUEL — Wed, 11 Mar 2009 12:14:56 GMT

Le Silverlight Control Toolkit comprend un contrôle fort utile pour les applications RIA : l’AutoCompleteBox. Malheureusement, sa propriété SelectedItem est en lecture seule, et ne permet donc pas de faire du Binding dessus. Il existe 2 solutions à ce problème :

1. Télécharger les sources associées au ChangeSet 10371 ou supérieur sur le site CodePlex et recompiler le toolkit

2. Passer par une attached property (seule solution garantissant qu’il n’y ait pas de Breaking Change):

public class AutoCompleteHelper : DependencyObject
    {
        public static bool GetBound(DependencyObject obj)
        {
            return (bool)obj.GetValue(BoundProperty);
        }

        public static void SetBound(DependencyObject obj, bool value)
        {
            obj.SetValue(BoundProperty, value);
        }

        // Using a DependencyProperty as the backing store for Bound. This enables animation, styling, binding, etc...
        public static readonly DependencyProperty BoundProperty =
            DependencyProperty.RegisterAttached("Bound", typeof(bool), typeof(AutoCompleteHelper), new PropertyMetadata(false,
                (sender, args) =>
                {

                    var box = sender as AutoCompleteBox;
                    if ((bool)args.NewValue)
                        box.SelectionChanged += box_SelectionChanged;
                    else
                        box.SelectionChanged -= box_SelectionChanged;
                }));

        static void box_SelectionChanged(object sender, SelectionChangedEventArgs e)
        {
            var box = sender as AutoCompleteBox;
            SetSelectedItem(box, box.SelectedItem);
        }

        public static object GetSelectedItem(AutoCompleteBox obj)
        {
            return (object)obj.GetValue(SelectedItemProperty);
        }

        public static void SetSelectedItem(AutoCompleteBox obj, object value)
        {
            obj.SetValue(SelectedItemProperty, value);
        }

        // Using a DependencyProperty as the backing store for SelectedItem. This enables animation, styling, binding, etc...
        public static readonly DependencyProperty SelectedItemProperty =
            DependencyProperty.RegisterAttached("SelectedItem", typeof(object), typeof(AutoCompleteHelper), new PropertyMetadata(null,
                (sender, args) =>
                {
                    var box = sender as AutoCompleteBox;
                    var txt = string.Empty;
                    if (args.NewValue != null)
                        txt = args.NewValue.ToString();
                    box.Text = txt;
                    SetBound(box, true);
                }));

}

Ensuite, dans le xaml il suffira de faire:

<tk:AutoCompleteBox ItemsSource="{Binding ItemsSource}"
c:AutoCompleteHelper.SelectedItem="{Binding TheSelectedItem, Mode=TwoWay}"
c:AutoCompleteHelper.Bound="true" />

Enjoy !