Développement Silverlight : Concevez vos applications professionnelles sur Silverlight

Silverlight est devenue une plateforme solide permettant le développement et le déploiement d'applications métier.

Gill Cleeren et Kevin Dockx

Seulement trois petites années se sont écoulées depuis la révélation par Microsoft de Silverlight. C'est lors du Mix07 à Las Vegas que nous avons tous vu la première version de Silverlight, la nouvelle plateforme d'application Internet riche (RIA) de Microsoft. Aujourd'hui, Silverlight est devenue une plateforme prête pour le développement et la tenue à jour d'applications professionnelles.

Silverlight 1.0 était dotée d'un modèle de programmation basé sur XAML et JavaScript. Ce dernier n'est pas la solution idéale pour la création d'applications d'entreprise. Cette première version était par conséquent principalement utilisée dans des scénarios centrés sur les supports. Lors du lancement de Silverlight 2, cette plateforme est devenue un excellent candidat pour le développement d'applications métier. La principale modification portait sur la possibilité de réaliser le code en .NET (C# ou VB.NET) au lieu de JavaScript.

Pour « tester » les fonctionnalités de Silverlight et son adéquation pour la création d'applications métier, nous avons composé une courte liste d'achat correspondant à la configuration minimale type d'une application professionnelle. Nous verrons si Silverlight est en mesure de répondre à ces exigences.

Données, données, données

Qu'est-ce qui vous vient à l'esprit lorsque vous pensez à des applications professionnelles ? Données est le maître mot. Les applications Silverlight s'exécutent côté client, à l'intérieur du navigateur. Les données quant à elles résident dans une base de données côté serveur. Si l'on observe les espaces de noms et assemblys Silverlight, il n'y a pas de prise en charge ADO.NET. Les très populaires fonctionnalités telles que DataReaders ou LINQ-To-SQL ne sont par conséquent pas prises en charge.

De plus, Silverlight ne dispose pas d'une base de données côté client. Dans de nombreux cas, cela ne serait pas non plus une solution. Vous ne voudriez certainement pas stocker par erreur une copie temporaire d'une base de données contenant des informations sensibles sur la machine d'un client.

La solution est simple : ajoutez à la base de données une couche de service. Vous pouvez utiliser cette couche de service pour vous connecter à la base de données, de préférence via une couche métier. Du côté client, Silverlight peut alors se connecter à ces services et avoir accès aux données (voir Figure 1).

Figure 1 Silverlight peut se connecter à ces services côté client.

Silverlight prend en charge les types de services suivants : ASMX, WCF et REST. Vous pouvez également utiliser Silverlight pour consommer des types de services plus exotiques, par exemple des sockets et net.tcp. C'est une bonne nouvelle si vous ajoutez Silverlight à une pile technologique existante au sein de votre entreprise. Les services depuis lesquels Silverlight peut obtenir ses données sont identiques à ceux que vous utiliseriez pour d'autres types d'applications.

D'un point de vue Silverlight, le travail est le même avec des services ASMX et WCF. Si vous êtes en phase d'implémentation du service, optez pour WCF par défaut. Examinons un exemple basique de connexion à un service WCF. La première étape consiste à définir les fonctions du service. Ce service renvoie une liste de produits :

[ServiceContract(Namespace = "")]
publicclassOrderService
{
[OperationContract]
publicList<Product> GetAllProducts()
        {
...
        }
    }

Une fois le service prêt, nous pouvons nous connecter en utilisant Silverlight. Pour cela, ajoutez une référence de service depuis Visual Studio (voir Figure 2).

Figure 2 Utilisez Visual Studio pour ajouter une référence de service à Silverlight.

À présent, Visual Studio va créer pour nous une classe proxy. Vous pouvez considérer qu'une classe proxy est une copie côté client de la classe de service, où les implémentations de méthodes sont remplacées par un appel de la méthode de service. Dans Silverlight, communication du service se produit de manière asynchrone. Dans l'exemple de code ci-dessous, nous utilisons ce proxy pour obtenir une liste de produits :

privatevoid button1_Click(object sender, RoutedEventArgs e)
{
OrderService.OrderServiceClient proxy = new OrderService.OrderServiceClient();
       proxy.GetAllProductsCompleted += newEventHandler<OrderService.GetAllProductsCompletedEventArgs>(proxy_GetAllProductsCompleted);
       proxy.GetAllProductsAsync();
}

void proxy_GetAllProductsCompleted(object sender, OrderService.GetAllProductsCompletedEventArgs e)
{
ProductGrid.ItemsSource = e.Result;
}

REST est actuellement un protocole répandu en raison de sa large adoption dans les API Web 2.0 telles que Facebook et Twitter. Silverlight en assure également la prise en charge complète. Silverlight est aussi dotée d'une infrastructure de service spécifique développée en s'inspirant d'applications Silverlight multiniveau : Services WCF RIA.

Découvrez le multiniveau

Lors de la création d'une application Silverlight, vos données viendront généralement d'une couche de service. Néanmoins, il n'existe pas de manière facile et toute faite permettant d'écrire simplement en une seule fois vos classes et objets de transfert de données, y compris la validation, l'authentification/autorisation. Les applications Silverlight sont conçues en s'appuyant sur une version limitée de Microsoft .NET Framework 4. Par conséquent, vous ne pouvez pas faire référence à un assembly (par exemple, un assembly qui contiendrait vos classes/logique de validation) s'appuyant sur la version complète de .NET Framework 4 dans une application Silverlight.

C'est à ce stade que les services WCF RIA entrent en action. Ils ont été créés afin de simplifier le développement RIA métier. Ils gèrent la complexité de la création d'applications multiniveau en fournissant une infrastructure, des contrôles et des services à la fois côté serveur et côté client.

Ils vous permettent d'écrire des services associés à une banque de données côté serveur. Il peut s'agir d'une base de données SQL Server, de vos propres classes POCO ou d'un modèle d'entité. Ces entités sont alors régénérées sur votre client. Ce sont ensuite les opérations, les méthodes et le contexte nécessaires qui sont générés sur votre client afin de communiquer facilement avec vos services.

Si vous maîtrisez déjà Entity Framework, vous vous sentirez tout à fait à l'aise. Le code s'effectue en effet de manière très similaire. Par exemple, vous pouvez disposer d'un DomainContext côté client qui suit les ensembles de modifications, contient des listes d'entités et vous permet de soumettre ces modifications. Cela « masque » le fait que vous travaillez via une couche de service.

Les services WCF RIA sont essentiellement une technologie côté serveur qui projette du code à un client. Ils simplifient également la procédure d'ajout d'une validation et d'une autorisation/authentification à vos services et entités. Ils réduisent nettement le délai de développement que vous consacrerez à la création d'application Silverlight métier.

Problèmes de contrôle

Silverlight est dotée d'un ensemble de contrôles complet contenant des contrôles simples, par exemple des boutons, des TextBoxes et des zones de liste déroulante. Elle comporte également des contrôles plus avancés tels que DataGrid, RichTextBox et le MediaElement du package d'installation par défaut. Microsoft ajoute des contrôles à chaque nouvelle version.

Microsoft a également créé le kit d'outils de contrôle Silverlight. Il s'agit d'un ensemble de contrôles supplémentaires qui sont open source et disponibles gratuitement sur CodePlex.com. Ce package est mis à jour régulièrement et hors-bande avec les versions régulières de Silverlight.

Il inclut de nombreux contrôles susceptibles de simplifier encore votre tâche de développeur Silverlight d'entreprise. Il comporte également des contrôles graphiques qui peuvent s'avérer pratiques pour notre prochaine requête : la création de rapports.

Possibilités d'impression

L'impression demeure une exigence d'entreprise courante. Désormais, avec Silverlight 4, vous pouvez imprimer directement depuis Silverlight. Cette API vous permet d'indiquer ce que vous voulez imprimer, s'il s'agit de l'ensemble de l'écran ou d'un contenu généré dynamiquement, un rapport par exemple. Ainsi, vous créez facilement une solution de création de rapports dans Silverlight 4, conjointement avec les contrôles disponibles dans le kit d'outils, par exemple des graphiques enrichis.

Modèles et meilleures pratiques

Lorsque vous travaillez avec Silverlight, ou des applications basées sur XAML, un point important à considérer repose sur les différences en termes d'écriture du code en comparaison des codages auxquels nous sommes habitués avec des technologies plus anciennes, par exemple ASP.NET ou Windows Forms. Vous pouvez écrire le code de la même manière, mais ça n'est pas conseillé. En effet, vous n'exploiteriez pas ainsi la technologie de manière optimale.

Les applications Silverlight doivent reposer amplement sur DataContext, liaison de données et le modèle Observateur. Vous ne devriez rencontrer aucun code répétitif pour affecter des valeurs TextBox à des objets ou vice-versa. Plus vous devez écrire ce type de code, plus vous êtes susceptible d'introduire un bogue dans votre code. Vous liez un objet à des éléments d'interface utilisateur et les valeurs correctes sont automatiquement disponibles via l'objet dans le code. En fait, vous ne devriez jamais accéder directement à des éléments d'interface utilisateur.

C'est à ce stade que le modèle de conception Modèle-Vue-VueModèle (MVVM) entre en jeu. Il est souvent utilisé pour encourager la séparation des responsabilités (votre code-behind contient peu voire pas de code). Il vous permet de travailler sur l'interface utilisateur de votre application séparément du développeur. Il améliore également la testabilité du code.

Néanmoins, le principal avantage qu'il offre est qu'il encourage les développeurs à tirer le meilleur profit de la puissance de la technologie DataContext et liaison de données. Votre Vue est doté d'une VueModèle en tant que DataContext qui contient toutes les propriétés des données.

Ces propriétés sont liées aux éléments de l'interface utilisateur dans la Vue via la liaison de données. Ainsi, VueModèle convertit essentiellement les données obtenues du Modèle (une représentation d'objet de vos données) en données que la Vue peut utiliser. Vous pouvez considérer qu'une VueModèle est « un convertisseur survitaminé ».

Une fois cela en place, vous aurez besoin d'un moyen de relayer vos événements (un clic de bouton par exemple) vers la VueModèle au lieu du code-behind des Vues. Vous pouvez le faire via une commande. Silverlight fournit une interface ICommand et vous pouvez lier la base de bouton héritée d'éléments d'interface utilisateur à des commandes. Ces commandes sont définies sur la VueModèle.

Vous aurez ensuite besoin d'un moyen pour communiquer entre différentes VueModèles, sans que ces dernières disposent de références entre elles. Vous pouvez le faire via un principe diffusion/écoute. Les abonnés VueModèle reçoivent un certain type de message, alors qu'une autre VueModèle envoie un autre message. Vous pouvez entreprendre les actions nécessaires une fois que vous recevez le message.

Enfin, vous devrez vous assurer que votre Vue sait quel devrait être son DataContext. Il existe différentes approches : la première approche Vue (la Vue est instanciée par l'application et est responsable de l'instanciation de la VueModèle dont elle a besoin) ou bien la première approche VueModèle (procédure inverse). Elles utilisent souvent un conteneur IoC ou Managed Extensibility Framework (MEF) pour répéter les responsabilités.

Il existe quelques implémentations différentes de MVVM. Vous pouvez écrire la vôtre propre mais la communauté open source dispose déjà d'excellentes implémentations, par exemple une boîte à outils MVVM Light, Caliburn ou Prism.

Comme vous pouvez le voir, Silverlight est prête pour la création d'applications d'entreprise. En fait, nous le faisons tous deux au quotidien.

Gill Cleerenest directeur régional Microsoft (theregion.com), MVP ASP.NET, membre du bureau des conférenciers INETA et Silverlight Insider. Il vit en Belgique où il occupe un poste d'architecte .NET chez Ordina. Il est l'auteur de nombreux articles parus dans plusieurs magazines de développeurs et il a publié récemment son premier livre : « Silverlight 4 Data and Services Cookbook », (Packt Publishing, 2010). Vous pouvez consulter son blog à l'adresse suivante : snowball.be.

Kevin Dockxest un spécialiste technique/chef de projet sur des applications Web .NET pour RealDolmen, une des plus importantes entreprises ICT de Belgique. Il s'intéresse tout particulièrement à Silverlight tout en gardant un œil sur les nouveaux développements concernant d'autres produits de la pile Microsoft .NET (Web). Il intervient régulièrement lors de manifestations nationales et internationales. Par exemple, Microsoft DevDays au Pays-Bas, Microsoft Techdays au Portugal ou des rassemblements BESUG (Belgian Silverlight User Group). Son blog, qui contient plusieurs informations croustillantes concernant Silverlight, .NET et divers commentaires, est disponible à l'adresse suivante blog.kevindockx.com.

Contenu associé

• Le Cache Web ASP.NET favorise performances et évolutivité
• Évolutivité pour les applications ASP.NET
• Gestion et délégation d'ASP.NET