Cet article fait partie d'une série expliquant comment architecturer une application d'entreprise Silverlight centrée sur les données. Silverlight, lorsqu'elle est combinée avec les patterns les plus populaires aujourd'hui et certaines technologies-clés pour le génie logiciel, peut être une technologie très productive, simple, fiable et efficace pour construire ce genre d'applications, et en même temps, fournir une expérience utilisateur exceptionnelle.

Langage/Outil/Technologie : Silverlight 4.

Commentez ce tutoriel : Commentez

- Titre : Architecturer des applications métier Silverlight

- Auteurs : Manuel Felicio, Deepin Prayag

- Parution : 17 janvier 2013

- Mise à jour : 5 mars 2013

- Licence : Copyright © 2013 Manuel Felicio. CDATA[Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC. Cette page est déposée à la SACD.

Sommaire

- Traduction

- Architecturer des applications métier Silverlight - Construire un framework MVVM

- Conclusion

- Liens

- Remerciements

Traduction

Cet article est la traduction la plus fidèle possible de l'article de Manuel Felicio, Architecting Silverlight LOB applications (Part 6) - Building an MVVM Framework (1).

Architecturer des applications métier Silverlight - Construire un framework MVVM

Dans cet article, je vais parler de la construction d'un framework MVVM.

Comme je le disais dans l'article précédent, cet article devrait être sur l'OrderView. Cette vue devrait permettre aux utilisateurs de choisir des éléments d'une liste de produits, les ajouter à la commande en cours, choisir les quantités, voir le prix total actuel et soumettre la commande. Aussi, l'utilisateur doit être en mesure de filtrer, trier et avoir une pagination sur la liste des produits. Je suis sûr que vous avez vu pleins d'articles et de billets de blogs d'autres personnes parlant de ce sujet, c'est-à-dire obtenir le produit sélectionné, l'ajouter à une autre collection ou créer un détail de la commande basé dessus, puis mettre à jour certaines autres données sur l'interface utilisateur et, enfin, soumettre les modifications au serveur. Le truc, c'est que tout le monde a sa propre façon de programmer et lorsque vous vous retrouvez éventuellement dans une équipe, il se peut que vous constatiez que deux personnes ont codé la même chose d'une manière différente, et que l'une a un bogue dans la situation A et l'autre a un bogue dans la situation B. Avoir un bon framework MVVM avec une méthodologie bien définie est indispensable pour prévenir ces situations. Dans cet article, je souhaite parler des composants essentiels que vous devez avoir dans un bon framework MVVM. Je vous décrirai par la suite un framework MVVM sur lequel je travaille qui était basée sur WCF RIA Services, mais dont il ne dépend pas vraiment.

Puisque nous suivons les bonnes pratiques, nous savons qu'en utilisant une bonne architecture MVVM nous pouvons arriver à une solution dont la logique d'extraction, de filtrage, de tri, de pagination est entièrement séparée de la vue, nous permettant d'avoir aussi des vues différentes pour le même viewmodel. Par exemple, nous pouvons commencer par utiliser un DataGrid et un DataPager pour afficher nos articles, mais plus tard, fournir une nouvelle vue qui utilise des combobox pour sélectionner les options de tri, une listbox de type album pour afficher les articles et des boutons personnalisés pour la pagination. De même, nous devrions être en mesure de séparer toute cette logique de sa logique d'accès aux données réelles pour pouvoir utiliser des objets factices pour notre modèle et d'effectuer des tests unitaires pour nos viewmodels. Ce n'est pas une tâche facile mais c'est ce que je souhaite réaliser à partir de maintenant.

Eh bien, pour commencer, .NET/Silverlight nous offre déjà quelques classes et interfaces qui sont très pratiques dans le cadre de scénarios MVVM.

- INotifyPropertyChanged - Utilisée pour déclencher un événement lorsqu'une propriété change. Le framework de liaison WPF/Silverlight utilise cette interface pour mettre à jour la vue lorsqu'une propriété change.

- INotifyCollectionChanged - Utilisée pour déclencher un événement lorsqu'une opération d'insertion, de suppression, d'effacement ou de remplacement a été effectuée sur une collection. Les contrôles WPF/Silverlight qui ont une propriété ItemsSource utilisent d'habitude cette interface pour créer ou supprimer des éléments visuels dans un conteneur. Par exemple, des ListBox affichent de nouvelles ListBoxItem, des DataGrid affichent de nouvelles DataGridRow.

- ICollectionView - Utilisée pour fournir le filtrage, des descriptions de tri, des descriptions du groupe, et la sélection d'items pour une collection IEnumerable et faire que la vue n'affiche que les éléments filtrés, triés selon les descriptions de tri et mettre en évidence l'élément sélectionné. (Possède davantage de fonctionnalités, mais ce sont les plus pertinentes dans le cadre de cet article).

- IPagedCollectionView - Utilisée pour fournir des options de pagination à une collection IEnumerable. Celles-ci sont utilisées essentiellement par des DataPager, qui font des appels à la méthode MoveToPage(int pageIndex) et nous permettent d'enregistrer dans l'événement PageChanging et d'aller chercher une nouvelle page d'entités à afficher.

- Il existe d'autres interfaces importantes telles que IEditableObject et IEditableCollectionView, mais je ne les aborderai pas dans cet article. Elles sont utilisées pour mettre à jour les valeurs des propriétés d'un objet de façon atomique.

Malheureusement, les collections WCF RIA Services n'implémentent pas ICollectionView ou IPagedCollectionView, donc nous devons fournir notre propre mécanisme de filtrage, de tri et de pagination des données. Toutefois, cela est assez facile à faire avec LINQ et la classe Expression et nous pouvons composer des requêtes avec certains opérateurs de LINQ avec WCF RIA Services. Silverlight a sa propre implémentation de IPagedCollectionView, appelée System.Windows.Data.PagedCollectionView mais elle a été conçue pour fonctionner avec les collections en mémoire et non pas les « collections » (sources de données) côté serveur. Dans cette série, je fournis ma propre implémentation IPagedCollectionView/ICollectionView que j'ai conçue pour fonctionner avec n'importe quel type de sources de données. Quelle que soit l'option utilisée cela revient entièrement au modèle dans MVVM.

Donc, voyons comment fonctionne mon framework MVVM.

Tout d'abord, nous avons le concept du modèle :

1. public interface IDomainModel : IDisposable
2. {
3.     void RejectChanges();
4.     ISubmitOperation SaveChanges();
5.     ISubmitOperation SaveChanges(Action<ISubmitOperation> callback, object userState);
6.
7.     IDomainQuery<T> GetQuery<T>();
8.
9.     void Add<T>(T entity);
10.     void Remove<T>(T entity);
11.     void Attach<T>(T entity);
12.     void Detach<T>(T entity);
13.
14.     bool HasChanges { get; }
15.     bool IsSubmitting { get; }
16.     bool IsLoading { get; }
17. }

Si vous êtes familier avec l'API DomainContext, vous trouverez cette interface très facile à comprendre. Cette interface modèle est censée vous fournir des fonctionnalités de base pour extraire des données, les modifier et enregistrer les modifications. Pour des opérations plus spécifiques, vous pouvez étendre cette interface, ajouter des opérations spécifiques et faire en sorte que votre viewmodel en dépend.

L'interface IDomainQuery représente une requête sur un certain repository d'un type d'entité (quel qu'il soit). Comme une requête, elle vous permet de filtrer, trier et paginer les données.

1. public interface IDomainQuery : IDisposable
2. {
3.     void Cancel();
4.     void Load();
5.
6.     event Action Loading;
7.     event Action<ILoadOperation> Loaded;
8.     event Action Canceled;
9. }
10.
11. public interface IDomainQuery<T> : IDomainQuery
12. {
13.     /// <summary>
14.     /// Delegate that returns a lambda expression to apply in a Where operation
15.     /// </summary>
16.     Func<Expression<Func<T, bool>>> FilterExpression { get; set; }
17.
18.     /// <summary>
19.     /// SortDescription values that are applied in a OrderBy/ThenBy operation
20.     /// </summary>
21.     Func<SortDescriptionCollection> SortDescriptions { get; set; }
22.
23.     /// <summary>
24.     /// Contains the required data that are applied in a Skip and Take operation
25.     /// </summary>
26.     Func<PageDescription> PageDescription { get; set; }
27.
28.     new event Action<ILoadOperation<T>> Loaded;
29. }
30.
31. public sealed class PageDescription
32. {
33.     public int PageSize { get; set; }
34.     public int PageIndex { get; set; }
35. }

En outre, elle possède des événements pour vous permettre de savoir quand est-ce qu'elle a commencé et terminé une opération de chargement. Il y a deux choses importantes à noter dans l'interface IDomainQuery. La première est le fait que la façon dont vous filtrez une IDomainQuery est la même que pour filtrer une RIA Services EntityQuery, ou tout autre objet IQueryable. Cela signifie qu'il est très facile de réaliser des implémentations IDomainQuery qui interrogent les repositories en mémoire ou des repositories côté serveur (notez qu'EntityQuery n'implémente pas IQueryable et qu'il n'est pas facile d'intégrer les deux concepts). L'autre chose importante est que le mécanisme de filtrage, de tri, de pagination est basé sur les délégués, ce qui signifie que chaque fois que la requête est exécutée/ré-exécutée ces délégués sont toujours réévalués et vont toujours refléter l'état actuel de votre viewmodel.

Dernier point, mais non des moindres, nous avons les opérations. J'ai créé des interfaces pour les opérations « Load » et « Submit ». J'ai implémenté toutes ces interfaces avec des classes qui s'appuient sur WCF RIA Services. Je ne vais pas poster le code de ces classes, mais ils sont disponibles dans le dépôt du code source, donc vous pouvez l'y consulter.

Si vous êtes familier avec DomainContext, vous êtes sans doute en train de vous demander où sont les EntitySet et où vous pouvez manipuler les collections. Eh bien, puisque mon implémentation IDomainModel s'appuie sur WCF RIA Services, vous pouvez étendre cette classe et manipuler votre DomainContext pour implémenter toute opération que vous souhaitez rendre disponible dans votre IDomainModel étendue. Mais avec ce framework elles ne sont pas censées être accessible dans votre viewmodel. Au lieu de cela, j'utilise mon implémentation ICollectionView, que j'ai appelé DomainCollectionView.

1. public interface IDomainCollectionView : ICollectionView, IPagedCollectionView, INotifyPropertyChanged
2. {
3.     void Add(object item);
4.     void Remove(object item);
5. }
6.
7. public interface IDomainCollectionView<T> : IDomainCollectionView, IEnumerable<T>
8. {
9.     void Add(T item);
10.     void Remove(T item);
11. }

L'implémentation actuelle s'appuie sur une IDomainQuery et sera une vue pour les résultats qui sont récupérés au cours de chaque opération. Puisque vous pouvez implémenter une IDomainQuery pour toute IEnumerable vous pouvez utiliser cette implémentation pour n'importe quelle source de données.

1. public class DomainCollectionView<T> : ViewModelBase, IDomainCollectionView<T>
2. {
3.     private IDomainQuery<T> query;
4.     private ObservableCollection<T> sourceCollection;
5.
6.     #region DomainCollectionView Members
7.
8.     public DomainCollectionView(IDomainQuery<T> query, bool usePaging = true)
9.     {
10.         this.query = query;
11.         this.sourceCollection = this.CreateSourceCollection();
12.         this.CurrentItem = null;
13.         this.CurrentPosition = -1;
14.
15.         //Apply sort and paging
16.         query.SortDescriptions = () => this.SortDescriptions;
17.         if (usePaging)
18.         {
19.             this.canChangePage = true;
20.             this.pageSize = 10;// default page size to 10
21.             query.PageDescription = () => new PageDescription { PageSize = this.PageSize, PageIndex = this.PageIndex };
22.         }
23.
24.         query.Loaded += this.OnDataRefreshed;
25.     }
26.
27.     private void OnDataRefreshed(ILoadOperation<T> loadOp)
28.     {
29.         using (this.DeferRefresh())
30.         {
31.             this.sourceCollection.Clear();
32.             foreach (var entity in loadOp.Entities)
33.                 this.sourceCollection.Add(entity);
34.
35.             this.ItemCount = loadOp.TotalEntityCount;
36.             this.TotalItemCount = loadOp.TotalEntityCount;
37.         }
38.     }
39.
40.     //...
41. }

Maintenant que j'ai introduit le modèle et l'IDomainCollectionView, il est temps que nous parlions un peu du viewmodel.

Contrairement au modèle, les viewmodels ne sont pas tellement réutilisables, car ils dépendent généralement des besoins de la vue. Cependant, plusieurs vues dans les applications métier ont des besoins communs : la recherche/énumération des entités, édition des entités, créer des associations entre entités. Nous pouvons créer des viewmodels pour ces concepts et les étendre uniquement pour implémenter la logique métier. Toute l'infrastructure et la plomberie peuvent être centralisées et réutilisées partout.

Avant de terminer, je vais déposer simplement le premier jet d'un viewmodel de base qui peut être utilisé pour rechercher/énumérer des entités.

1. public class ListVM<T> : ViewModelBase, IListVM<T>
2. {
3.     private IDomainModel model;
4.
5.     public ListVM() { }
6.
7.     protected virtual IDomainModel CreateModel()
8.     {
9.         return ServiceLocator.Current.GetInstance<IDomainModel>();
10.     }
11.
12.     public void Initialize(IListVMInitializeArgs args)
13.     {
14.         this.model = args.ExistingModel ?? this.CreateModel();
15.         var query = model.GetQuery<T>();
16.         this.Entities = new DomainCollectionView<T>(query, args.RequiresPaging);
17.         query.Load();
18.     }
19.
20.     public IDomainCollectionView<T> Entities
21.     {
22.         get;
23.         private set;
24.     }
25. }

Avec seulement quelques lignes de code, nous avons un viewmodel de base qui peut :

- afficher des résultats d'une requête qui peuvent être triés et paginés sur le serveur. Liez simplement une datagrid à la collection Entities et manipulez-la ;

- réutiliser un modèle existant ou en créer un nouveau. L'implémentation actuelle peut utiliser un modèle partagé pour toute l'application qui est enregistré dans le conteneur d'injection de dépendances actuel ou laisser un viewmodel dérivé décider quoi faire.

Je vous laisse y réfléchir.

Conclusion

Cette série est maintenant terminée. À l'avenir je pourrais creuser davantage pour voir comment nous pouvons créer des viewmodels de base pour tous les concepts cités plus haut et ajouter plus de fonctionnalités aux viewmodels.

Liens

Pour terminer, je tenais à dire que tout le code est disponible sur http://code.google.com/p/mfelicio-wordpress sous trunk/2010/SL-MVVM-RIA.

Remerciements

Je tiens ici à remercier Manuel Felicio de m'avoir autorisé à traduire son article.

Je remercie tomlev pour sa relecture technique et ses propositions.

Je remercie également zoom61 pour sa relecture orthographique et ses propositions.

(1)Le blog de l'auteur et l'article en anglais ne sont plus accessibles depuis quelques semaines.
Retour à l'article

Architecturer des applications métier Silverlight

Partie 6 - Construire un framework MVVM

Auteurs

| Manuel Felicio | Deepin Prayag |