Lorsque vous créer des applications WPF, vous utilisez peu-être (en tout cas, vous devriez !) le patter M-V-VM and vous devez donc créer et utiliser des ViewModels.
Le rôle principal des viewModels est d'exposer les propriétés de vos objets métiers aux vues, prêtes pour utiliser le moteur de binding.

Afin d'utiliser le Binding, la solution la plus courante est d'implémenter INotifyPropertyChanged et de lever des événements pour chaque modification faite sur les données. Le hic, ce n'est pas toujours vous qui créez les objets métiers : une autre équipe le fait pour vous, ils transitent via des webServices, etc... Ils ne sont alors pas prêt pour le DataBinding. Vous devez donc trouver une solution pour créer un objet très similaire à l'objet métier MAIS qui sera prêt pour le binding...

Dans cette série de posts nous allons voir les différentes solutions à votre disposition... Aujourd'hui cela sera le wrapping !

Envelopper (wrapper) vos objets métiers

La première solution qui apparait dans chaque cerveau de développeur est d'envelopper les objets métiers dans un ViewModel. Chaque propriété de votre ViewModel sera en réalité une sorte de proxy vers l'objet métier sous-jacent.

Par exemple, considérons un objet métier tel que celui-ci :

///<summary>
///Je suis l'objet métier créé par une autre équipe et je ne suis pas bindable : honte à moi !
///</summary>
publicclass MyBusinessObject
{
public String LastName{get;set;}
public String FirstName{get;set;}
public int Age {get;set;}
public List<String> FriendsName {get;set;}
}

Nous créeons ensuite un ViewModel qui ressemblera à cela :

public class ViewModelWrapped : ViewModelBase
{
private MyBusinessObject _myBusinessObject;
private ObservableCollection<String> _friendsName;
public ViewModelWrapped(MyBusinessObject myBusinessObject)
{
  _myBusinessObject = myBusinessObject;
  _friendsName = new ObservableCollection<string>(myBusinessObject.FriendsName);
}
public String FirstName
{
  get { return _myBusinessObject.FirstName; }
  set
  {
    FirePropertyChanged("FirstName");
    _myBusinessObject.FirstName = value;
  }
}
public String LastName
{
  get { return _myBusinessObject.LastName; }
  set
  {
    FirePropertyChanged("LastName");
    _myBusinessObject.LastName = value;
  }
}
public int Age
  {
  get { return _myBusinessObject.Age; }
  set
  {
    FirePropertyChanged("Age");
    _myBusinessObject.Age = value;
  }
}
public ObservableCollection<String> FriendsName
{
  get { return _friendsName; }
  set
  {
    if (value != null)
    {
      FirePropertyChanged("FriendsName");
      _myBusinessObject.FriendsName = value.ToList<String>();
    }
  }
}
}

Notes : Quelque chose d'intéressant à remarquer est la façon dont nous wrappons les collections : pas très simple ! De plus les collections du modèle et du ViewModel ne sont plus synchronisée. En effet toutes les opérations seront faites sur la collection du ViewModel et non pas sur la collection du modèle.

Pour et contre

Pour :

• Les noms des propriétés exposées ne sont pas nécessairement celles des objets métiers : plus de souplesse.
• Le code reste très simple à lire.

Contre:

• C'est très fastidieux d'avoir à créer les propriétés et de les rediriger vers celles du modèle.
• Les collections du modèle ne sont pas synchronisée avec celles des viewsModel.
• Le copier-coller pour le mappage des propriétés peut conduire à des erreurs ...