L’infrastructure pour une application métier Silverlight ressemble sous certains points à celle d’une application Intranet avec toutefois des différences notables.
Découvrez ci-dessous la suite de notre dossier "Silverlight, l'alternative pour vos applications métier".
On retrouve classiquement les trois acteurs d’une application ASP.NET :
• Le serveur de base de données
• Le serveur Web accédant à la base de données et gérant le contrôle d’accès (en s’appuyant par exemple sur les Membership et Role Provider ASP.NET)
• Le navigateur accédant au serveur Web.
La différence réside dans le rôle que joue le navigateur dans cette architecture : lors de la connexion à l’application le navigateur ouvre une page Web classique. Cette page référence un package Silverlight (ces packages se présentent sous la forme de fichiers « .xap » qui sont déposés sur le serveur). Le navigateur initialise alors le moteur Silverlight qui se charge du téléchargement du package. Le package est alors exécuté au sein de cet environnement. Le navigateur n’est donc plus sollicité uniquement pour le rendu d’un contenu HTML.
Par la suite, le code silverlight peut télécharger à la demande des compléments et interagir avec les services exposés sur le serveur Web.
Contrairement à une application ASP.NET le code s’exécute donc en local et peut donc offrir une meilleure interaction avec l’utilisateur :
• Les allers-retours serveurs sont limités à de l’échange de données et uniquement quand cela est nécessaire.
• L’interface peut se mettre à jour sans contacter le serveur Web.
• Il est possible d’effectuer des traitements en local (tri, stockage, mise en forme, impression …).
• Sous certaines conditions l’application peut fonctionner en mode déconnectée, en dehors du navigateur.
• Le rendu de l’interface graphique est géré par la couche WPF de Silverlight, ce qui réduit grandement (voir complètement) les incompatibilités entre navigateurs.
La différence par rapport à une application ASP.NET apparaît de manière plus flagrante si l’on considère l’architecture logicielle de l’application. Celle-ci en effet, s’appuie sur le Framework et la CLR Silverlight, ce qui rapproche ce type de développement d’un développement WPF classique.
En effet, la présence de la technologie WPF au sein de Silverlight a poussé des architectures dissociant fortement la présentation des traitements et des données, ceci du fait de la présence d’un modèle de Binding très évolué.
Un exemple d’architecture typique est le modèle MVVM (Model, View, ViewModel).
L’intérêt de ce type d’architecture réside dans les points suivants :
Il est possible d’écrire des tests se substituant à l’IHM et interagissant avec le ViewModel.
Le code est séparé de l’interface ce qui peut améliorer la maintenance.
Enfin, la faible liaison entre le code (ici ViewModel) et l’interface (qui sera décrite par un fichier XAML = Fichier XML produit par le designer Visual Studio ou tout autre outil) permet une certaine liberté sur la conception de l’interface. En effet une application Silverlight est généralement conçue avec les contrôles standards (boite de saisie, liste, bouton …) mais peut ensuite être personnalisée par différents moyens :
• Un thème générique peut être appliqué aux contrôles.
• Des styles peuvent être élaborés, ces styles permettant, à l’extrême de redéfinir complètement les contrôles.
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
