Modèle de conception Silverlight pour les performances - interface client très riche

Question

Suite à this enquêtes initiales sur les architectures Silverlight, j'ai quelques nouvelles exigences à prendre en compte.

Nous nous attendons à notre interface utilisateur du client Silverlight pour être graphiquement lourd, avec une interface SIG, plusieurs graphiques, jauges et datagrids disposés en mode style Widget. Les nouveaux widgets seront générés dynamiquement par l'utilisateur.

Supposons un utilisateur voulait créer dynamiquement un widget graphique à partir d'un widget DataGrid existant prérempli avec les données. Il me semble que si nous utilisions un modèle MVVM avec le modèle de vue sur le serveur, cela entraînerait un appel inutile à la maison lorsque les données requises sont déjà situées dans le client.

Maintenant, évidemment, le serveur a besoin de connaître ce nouveau widget graphique sur le client, mais comment créer d'abord le widget dans le client (avec les données côté client) et ensuite informer le serveur des nouvelles modifications?

Dans notre intranet, le lien réseau entre le client et le serveur n'est pas particulièrement bon, donc les performances sont critiques.

Il semble de mes premières recherches que les modèles d'architecture Silverlight communs appellent autant de la logique métier d'être poussé vers le serveur. Je comprends le raisonnement pour cela, mais je crains que cela ne nuise vraiment à la convivialité de notre application.

Existe-t-il des modèles de conception particuliers qui résolvent ce problème? Est-ce que cette 'liaison client' est prise en charge dans MVVM, Prism ou d'autres architectures Silverlight communes?

Y at-il un nom plus formel pour ce que je tente de décrire?

Je suis tout à fait nouvelle à la fois Silverlight et modèles de conception tels que MVVM, donc s'il vous plaît me corriger si mes hypothèses sont fausses.

Answer 1

Le modèle MVVM sert à séparer les problèmes. Il ne définit ni comment ni où vous obtenez vos données.

Le modèle est des données. Il peut s'agir de données provenant de n'importe quelle source arbitraire. Dans Silverlight, le moyen le plus courant d'obtenir des données est via un service Web (SOAP/REST). Mais votre modèle peut être n'importe quelles données de n'importe où.

Le modèle de vue est juste une autre classe qui implémente l'interface probablement INotifyPropertyChanged (vous pouvez les liaisons automatiquement mis à jour). Cette classe est une abstraction pour les données de votre vue. Supposons qu'il a une propriété de chaîne appelée "FirstName".

La vue est votre interface utilisateur (Un contrôle utilisateur dans SL). Vous configurez vos liaisons ici sur votre ViewModel. C'EST À DIRE, .

La vue et le modèle de vue sont regroupés lorsque vous définissez vos vues DataContext. myView.DataContext = nouveau MyViewModel(); Il existe plusieurs façons de définir le DataContext en fonction de la manière dont vous voulez configurer les choses.

Prism est juste un cadre pour aider à écrire des applications découplées dans WPF/SL. Il n'applique pas l'utilisation d'un modèle d'interface utilisateur (MVP/MVC/MVVM). Qu'est-ce qu'il vient avec un tas de classes peuvent être utilisés pour aider au développement de MVVM, comme un médiateur (EventAgggregator) et un conteneur d'injection de dépendance (Unity).

donc assez écartons ... Ce que je suggère, est que vous avez un service Web où vous pouvez obtenir toutes vos données. Votre application SL obtiendrait ces données (de la même manière que les services Web seront appelés dans le modèle de vue).Ces données existent maintenant du côté client et vous pouvez configurer votre VM pour lier à ces données dans votre vue.