Les fonctionnalités de Visual Studio.NET Accueil > Articles > Développement
Auteur		3/5 Assez Bien 51166 37/114

Les fonctionnalités de Visual Studio.NET

Pré requis : Cet article s'adresse aux personnes intéressées par les nouvelles fonctionnalités de l'architecture .NET. Il suppose des connaissances dans les domaines suivants :

• La programmation orientée objet (POO).
• L'accès aux données avec les ADO.
• L'environnement Internet.

Note : Cet article fait suite à l'article intitulé Présentation de la nouvelle architecture Visual Studio.NET et considère que la signification des acronymes CLR et IL vous soit connue.

Présentation de la nouvelle architecture Visual Studio.NET

Sommaire de l'article

• Introduction
• Une bibliothèque de classes homogène
• Les services du CLR
• Une nouvelle approche des accès aux données
• Un déploiement grandement simplifié
• Les applications Internet (ASP+)
• Les services WEB

Introduction

En reprenant le schéma ci-dessous présenté dans l'article précédent, nous savons qu'il est possible d'utiliser n'importe quel langage compatible avec l'architecture .NET (il en existe déjà plusieurs dizaines et rien ne vous empêche de créer le vôtre !!!)

Remarque : Pour qu'un langage puisse s'intégrer à cette suite, il suffit en effet qu'il soit capable de générer des instructions en IL, qui manipulent des objets issus des classes de base. La véritable compilation est ensuite assurée par le CLR.

Le choix d'un langage est donc une affaire de goût puisque les performances obtenues seront les mêmes, que le code soit écrit en VB, en C# ou en Perl !

Les fonctionnalités de ce nouvel environnement ne sont donc pas réellement à ce niveau, mais à celui du CLR qui va faire l'objet de la suite de cette page.

[ Retour au sommaire de l'article ]

Une bibliothèque de classes homogène

Nous pouvons dire que le CLR est en quelque sorte le RunTime de Visual Studio.NET. Nous pouvons dire également que c'est ce runtime qui implémente les classes de base (aussi dénommées classes système).

Les fonctionnalités du CLR représentent donc en réalité, l'ensemble des fonctionnalités de ces classes. Autrement dit, ce sont ces dernières qui permettent de travailler avec tous les objets du système accessible à partir d'une application .NET. Inutile de dire qu'elles sont nombreuses ;-).

Les espaces de noms

Aussi pour avoir une chance de trouver la bonne, elles ont été classifiées de manière arborescente à partir d'une racine nommée System. On sépare ensuite les différents noms par un point pour séparer les différents niveaux lorsque l'on descend dans cette arborescence. Par exemple, les contrôles dédiés à la conception d'une interface d'application Windows sont regroupés dans l'espace de noms System.WinForms.Control, tandis que les contrôles dédiés à la conception d'une interface d'application Internet sont regroupés dans l'espace de noms System.Web.UI.Control.WebControls et System.Web.UI.Control.HtmlControls.

Note : Nous reviendrons plus en détail sur les nouveautés présentées dans cette page dans de futurs articles.

[ Retour au sommaire de l'article ]

Les services du CLR

Le rôle des différents objets implémentés par le CLR est naturellement d'offrir des services, que nous devons classifier en familles correspondant aux différents espaces de noms. C'est à ces différentes familles de services que nous allons nous intéresser ici.

Remarque : Sans peut être aller jusqu'à la notion de service, il faut également savoir que le CLR implémente une bibliothèque de types de données commune à tous les langages compatibles .NET. Compte tenu du fait que toutes les classes du CLR sont elles aussi communes à ces mêmes langages, cette remarque signifie que deux composants distincts écrits avec 2 langages .NET différents seront compatibles, c'est-à-dire mutuellement accessibles en toute transparence vis à vis du langage utilisé.

[ Retour au sommaire de l'article ]

Une nouvelle approche des accès aux données

Nous n'avons pas choisi de parler du service d'accès aux données en premier par hasard ! C'est en effet celui que l'on retrouvera dans la plus grande majorité des applications.

Tout les développeurs connaissent à présent le modèle objet ADO qui permet d'accéder à tous types de sources de données. Ce modèle est constitué d'une demi-douzaine d'objets basés sur l'incontournable objet Recordset.

Compte tenu de la demande sans cesse grandissante en matière d'interropérabilité entre 2 systèmes, l'inconvénient majeur du modèle objet ADO est simple : il ne fonctionne que sous Windows du fait qu'il s'agit d'un composant COM.

Le modèle objet ADO a donc évolué en ADO+ au sein de .NET, de manière à traiter les données stockées dans le format XML qui s'est très vite révélé comme standard et universel, indépendamment de tout système.

Le modèle objet ADO+ est donc tout à fait différent de celui des ADO. L'objet principal, nommé DataSet, en est la racine. Ce dernier autorise par exemple la gestion d'une base de données complète de manière dynamique, c'est-à-dire déconnectée de toute source de données. Il peut ainsi se composer de tables, de vues et de relations. L'accès aux données se réalise ensuite par le biais d'un objet DataReader ou DataSet, mais nous reviendrons sur ces objets plus en détail dans un prochain article.

La clé de voûte de cette prouesse se nomme XML pour ne pas le citer. Contrairement aux objets ADO Recordset, un DataSet n'est pas un objet COM, mais un ensemble de données stockées au format XML !!!

Cet ensemble de données peut ainsi être traité sur n'importe quel système hébergeant un interpréteur XML.

Note : Pour vous familiariser avec le langage XML, n'hésitez pas à consultez notre présentation sur ce langage, avec une capture d'écran vidéo si vous disposez d'un lecteur de fichiers multimédia.

[ Retour au sommaire de l'article ]

Un déploiement grandement simplifié

Il n'est pas un développeur que je connaisse qui ne se soit pas heurté au moins une fois à un dysfonctionnement dû au problème d'enregistrement d'un composant COM dans la base de registre, c'est-à-dire, dans la grande majorité des cas, d'une fichue DLL de plus dans les entrailles de Windows/System32.

La source intarissable de ce genre de tracasseries ( ... potentielles  ;-)) vient justement du fait qu'un enregistrement soit nécessaire dans cette trop fameuse base de registre !

Mais il y a plus grave encore !! Les composants COM possèdent en effet la singulière particularité de se remplacer mutuellement dans la mesure où ils possèdent le même nom avec 2 numéros de version différents. Jusque là, il n'y a rien à redire me direz-vous, mais si l'on sait qu'un tel composant peut être partagé par N applications, les ennuis commencent ;-(.

Fort heureusement, ce scénario cauchemardesque "risque" (;-)) de prendre fin avec .NET qui solutionne ce problème épineux avec deux concepts implémentés par ce que l'on appelle des Assemblages, à savoir :

• Il n'est PLUS NECESSAIRE D'INSCRIRE UN COMPOSANT .NET NULLE PART pour qu'il fonctionne !!!
• Plusieurs versions d'un même composant peuvent cohabiter sans se voir mutuellement.

Et devinez qui est l'auteur de cette nouvelle prouesse ? Si je vous répond le XML, vous allez cesser de me prendre au sérieux dans la minute qui suit ;-). Et pourtant si, c'est encore lui l'auteur !

Un assemblage est tout simplement constitué d'un ensemble de fichiers de ressources (DLL, images, documentation, etc.) dont une application a besoin pour fonctionner. Le rôle d'un assemblage consiste donc à décrire l'ensemble de ces fichiers, avec pour chacun d'eux un nom et une clé cryptée permettant d'authentifier le fichier.

Naturellement, un assemblage se caractérise par des informations qui lui sont propres telles que :

1. un nom,
2. un numéro de version,

ainsi qu'un lot d'informations concernant les attributs de sécurité requis pour le bon fonctionnement de ce composant.

Il peut en outre comporter une liste de références à d'autres assemblages, avec leur numéro de version pour chacun d'eux.

Les applications Internet (ASP+)

Il est difficile de terminer cette brève description des nouvelles fonctionnalités de la suite VS.NET sans parler des ASP (Active Server Pages) qui ont eu tant de succès dans la communauté des développeurs d'applications WEB sous Windows/IIS.

Les nouveautés de ASP+ vont, en réalité, bien au-delà d'une simple fonctionnalité puisqu'il autorise désormais le développement d'une application WEB dans le même environnement (l'IDE de VS.NET) que celui dédié aux applications Windows.

Autrement dit, on bénéficie de toute la puissance des langages compatibles .NET, avec les même possibilités de débogage et surtout, des performances comparables puisque les applications ASP+ pourront se compiler !!! Pour résumer la situation, on peut dire que Visual Interdev est devenu totalement caduc, c'est-à-dire obsolète dans le jargon d'informaticien ;-).

Note : IDE (Interface Development Environment) signifie Interface de Développement Intégré.

Les services WEB

Le dernier point fort des nouvelles fonctionnalités de .NET s'appelle Service WEB. La mise en oeuvre d'un service peut se décrire comme étant la possibilité d'exploiter les fonctionnalités d'un composant COM à partir d'Internet. Ceci revient donc à dire qu'un service Web  est basé sur le protocole HTTP et non plus sur la "tuyauterie" COM dédiée à l'environnement Windows.

Et quel le nom du responsable de cette nouvelle prouesse ? ;-)

Mais c'est bien sûr : toujours notre langage XML ! Mais cette fois-ci, pour se marier avec le protocole HTTP, il doit s'associer avec un nouveau protocole nommé SOAP (Simple Object Access Protocol) (ou encore, plus récemment XMLP) qui a été spécialement conçu à cet effet par l'IETF (Internet Engineering Task Force). Cet organisme est en réalité une communauté regroupant des développeurs, des opérateurs, des chercheurs, etc., dans l'intention d'améliorer le fonctionnement d'Internet (profitons de ce cours instant pour les saluer respectueusement au passage).

[ Retour au sommaire de l'article ]

En Savoir Plus

Evaluez cet article  0 1 2 3 4 5 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft