Jiri's Shared IT knowledge

mardi, août 23, 2005

Microsoft Office SharePoint Portal Server 2003 Discovery Kit


Tout ce qu'il vous faut pour découvrir en douceur et en profondeur l'offre portail de Ms, à travers 6 labs clé en main
  • Une installation clé en main (d'un extreme clareté avec Windows, IIS, SQL, SPS, AD et reporting services via la VPC : un must !)
  • Personnalisation du moteur de recherche
  • Gestionnaire de personnalisation et audience
  • SSO et Reporting Services avec ses WebPart : (un must aussi !!!)
  • Personnalisation et charte graphique
  • infrastructure et performance (gestion des pools et indexs)

Le seul défaut de ces labs est d'etre juste en anglais ...

Cheminement , best practices, captures d'ecran, vous ne pouvez vous tromper il suffit de suivre pas à pas le fil conduteur des labs.

Bref, ces sont d'une qualité redoutable, je ne saurais trop vous les conseiller pour bien débuter

jeudi, août 18, 2005

ADO.NET: toutes les nouveautés de la version 2.0

Cette nouvelle mouture apporte de nombreuses améliorations. Elle vous imposera cependant peut-être de revoir votre code d’accès aux données. Tour d’horizon des principales évolutions.

Maintenant que les développeurs ont entre les mains la première version alpha publique de la prochaine mouture de Visual Studio .NET ("Whidbey"), il est temps qu'ils commencent à penser à leurs applications et à la manière dont elles pourraient être affectées par le passage à cette nouvelle version. Si la transition entre les versions 1.0 et 1.1 de l'environnement .NET Framework s'est déroulé en douceur et impliquait principalement la résolution de bugs, une amélioration des performances et l'intégration de technologies auparavant distinctes, telles qu'ODBC et Oracle .NET Data Providers, la version 2.0 change la donne pour ce qui est de l'accès aux données. Elle inclut en effet une multitude de nouvelles fonctionnalités, dont certaines peuvent vous amener à revoir complètement le mode d'accès et de manipulation des données dans vos applications.

Dans cet article, je présenterai brièvement les nouvelles fonctionnalités d'ADO.NET qui sont, à mon sens, les plus importantes, et je vous expliquerai comment les exploiter dans vos implémentations

Offrir une vue plus étendue des données

Avant d'explorer les fonctionnalités spécifiques d'ADO.NET 2.0, je commencerai par rappeler que l'un des objectifs de conception généraux de cette version était de favoriser un degré plus élevé d'interopérabilité entre les données accédées relationnellement, au format XML et en tant qu'objets personnalisés. Comme ces trois types de données constituent le "triangle d'or" pour représenter les données dans une application, ADO.NET 2.0 a été conçu pour permettre aux développeurs d'utiliser plus facilement le modèle adéquat au moment voulu dans et entre les applications.
Par exemple, dans les applications conçues à l'aide d'une architecture orientée services (SOA), les données opérationnelles persistantes seront souvent manipulées de manière relationnelle. Les données qui représentent le processus et encapsulent les règles opérationnelles seront quant à elles manipulées en tant qu'objets, tandis que les données de message et de recherche qui doivent être sérialisées en vue de leur transfert seront gérées en tant que XML. Pour présenter les nouvelles fonctionnalités, je les ai séparées en deux grandes catégories : les nouvelles fonctionnalités qui favorisent cette vue plus étendue des données et les fonctionnalités qui améliorent ou étendent le paradigme relationnel.

Élargir l'environnement .NET
Deux nouvelles fonctionnalités importantes vous permettent d'étendre votre aptitude à traiter les données. Examinons chacune d'elles.

ObjectSpaces
Cette technologie a été exposée il y a plusieurs années à l'occasion de la conférence des développeurs Microsoft et sera désormais intégrée à Whidbey. En deux mots, ObjectSpaces offre une couche de mappage relationnel objet dans le namespace System.Data.ObjectSpaces, qui instancie et complète les objets personnalisés à partir d'une base de données relationnelle. Pour ce faire, cette technologie utilise les métadonnées XML stockées dans un fichier de mappage qui est transmis au constructeur de la classe ObjectSpace, qui mappe les objets relationnels avec les objets .NET et les types relationnels avec les types .NET.

Ce modèle de programmation supporte les requêtes (ObjectQuery) et gère les jeux d'objets en mémoire (ObjectSet), l'accès aux flux d'objets (ObjectReader) et même le chargement lent d'objets pour améliorer les performances (ObjectList et ObjectHolder).

Même si dans la version actuelle, ObjectSpaces ne fonctionne qu'avec SQL Server 2000 et SQL Server "Yukon" (la version de SQL Server plus ou moins synchronisée avec Whidbey), cette technologie sera étendue pour permettre à l'avenir l'accès à d'autres espaces de stockage des données relationnelles. La technologie ObjectSpaces est idéale lorsque vous voulez représenter vos données à l'aide d'un modèle de domaine et encapsuler la logique applicative en tant que méthodes dans vos objets personnalisés, car elle vous évite de devoir écrire le code nécessaire pour charger vos objets depuis un espace de stockage des données relationnelles et en assurer la persistance.

SQLXML et XmlAdapter
Bien que le DataSet ADO.NET a toujours permis de charger les données en tant que XML et de sérialiser leur contenu en tant que code XML, la conversion entre les deux modes de représentation des données ne s'est jamais faite sans heurts. Par exemple, pour que le code XML puisse être chargé dans un DataSet, son schéma ne devait pas être trop complexe et il devait se mapper correctement dans les tables de données (DataTables) relationnelles du DataSet.

Si le support du XML par le DataSet a été amélioré dans la version 2 pour permettre de charger du XML avec plusieurs schémas en ligne, de charger des schémas avec des noms d'élément répétés dans différents namespaces, ainsi que de charger et sérialiser directement depuis les objets DataTable, les données doivent encore être relationnelles par nature pour fonctionner avec le DataSet. Pour y parvenir, la version 2 inclut la classe System.Xml.XmlAdapter. Celle-ci est semblable aux classes DataAdapter, dans la mesure où elle constitue un lien entre une source de données et une représentation des données, mais elle est utilisée pour interroger et charger du XML à partir d'une vue XML dans un objet XPathDocument (appelé XPathDocument2 dans la version alpha, mais reprendra le nom XPathDocument dans la version finalisée).

Les vues XML permettent de mapper les tables relationnelles (dans SQL Server uniquement) avec un schéma XML via des fichiers de mappages ; ces derniers constituent le composant fondamental de la technologie SQLXML 3.0, autrefois distincte du .NET Framework, mais désormais intégrée à ADO.NET 2 (y compris la possibilité de charger le XML en masse dans SQL Server) dans le namespace System.Data.SqlXml. Grâce à cette approche, vous pouvez fournir un jeu de vues XML pour vos données SQL Server, interroger les données avec le langage XQuery, à l'aide de la nouvelle classe XQueryProcessor et de la méthode Fill du XmlAdapter, et manipuler les données à l'aide des classes XPathDocument, XPathEditor, XPathNavigator et XPathChangeNavigator.

Les modifications sont répercutées sur SQL Server en appelant la méthode Update du XmlAdapter, qui s'appuie sur la vue XML pour rédiger les instructions SQL à exécuter à l'aide d'un fichier de mappages. L'avantage de cette approche est que vous pouvez traiter vos données SQL Server de la même manière que les autres espaces de stockage des données XML et que vous pouvez tirer profit de la fidélité sans faille du XML lorsqu'il s'agit d'apporter des changements.

Bien entendu, les vues XML se contentent de fournir le mappage des données vers et depuis SQL Server. Si vous n'utilisez pas SQL Server, vous pouvez toujours tirer profit des modifications substantielles apportées à XPathDocument (qui supplantera la classe XmlDocument et la rendra obsolète) et à ses classes associées pour faciliter l'interrogation, la navigation et l'édition du code XML chargé à partir d'autres sources.

Par exemple, vous pouvez utiliser une nouvelle classe XmlFactory afin de créer un jeu associé de classes XmlReader, XmlWriter et XPathNavigator pour un document XML. Ces classes supportent désormais la possibilité de lire et d'écrire des types .NET vers et depuis les documents XML. Bien entendu, les performances ont été améliorées pour lire et écrire avec XmlTextReader et XmlTextWriter ou utiliser XSLT.

Étendre le paradigme relationnel
La seconde grande catégorie de fonctionnalités se rapporte aux modifications apportées dans ADO.NET v2.0 pour améliorer l'accès aux bases de données relationnelles. Je les ai organisées en modifications dont tous les développeurs peuvent tirer profit, quelle que soit la base de données sous-jacente sur laquelle vous écrivez et quelles que soient celles qui nécessiteront SQL Server 2000 ou la prochaine version de SQL Server, Yukon.

Fabrique de fournisseurs
Bien que la conception des fournisseurs de données de .NET repose sur un jeu commun d'interfaces et de classes de base, dans les versions 1.0 et 1.1, Microsoft n'avait pas fourni de classes de fabrique pour aider les développeurs à rédiger un code d'accès aux données polymorphes. Par conséquent, les développeurs ont dû se débrouiller par eux-mêmes.

Dans la version 2, ADO.NET inclut des classes de fabrique héritées de system.Data.Common.DbProviderFactory pour créer les classes standard de connexion, de commande, de lecteur de données, de table, de paramètres, de permissions et d'adaptateurs de données. Ces classes vous aident à écrire du code ciblant plusieurs bases de données. L'accès à une fabrique se fait à l'aide de la méthode GetFactory de la classe DbProviderFactories. Vous pouvez configurer une fabrique dans le fichier de configuration de l'application à l'aide de la classe DbProviderConfigurationHandler.

Accès asynchrone aux données
Les commandes exécutées par ADO.NET dans la version 1.0 à l'aide des méthodes ExecuteNonQuery, ExecuteReader et ExecuteXmlReader de SqlCommand étaient synchrones et bloquaient le thread (tâche légère) en cours jusqu'à ce que le serveur ait renvoyé les résultats. Dans la version 2.0, chacune de ces méthodes inclut à la fois des versions Begin et End pour supporter l'exécution asynchrone du point de vue du client.

Cette technique suit le modèle de programmation asynchrone courant à l'aide du délégué AsyncCallback dans .NET et inclut donc la classe SqlAsyncResult pour implémenter l'interface IAsyncResult. Si cette fonctionnalité n'est pour l'instant opérationnelle que pour SqlClient, il y a de grandes chances pour qu'elle soit étendue à d'autres fournisseurs avant la sortie.

Mises à jour par lots
Dans la version 1.0, un objet DataAdapter envoyait toujours les modifications apportées aux lignes une par une au serveur. Dans la version 2.0, le DataAdapter expose une propriété UpdateBatchSize qui, si elle est prise en charge par le fournisseur de données, permet d'envoyer par lots les lignes modifiées au serveur. Cette procédure réduit le nombre d'allers-retours au serveur et améliore du même coup les performances.

Pagination des données
Dans SqlClient et OracleClient, l'objet Command expose désormais une méthode ExecutePageReader qui vous permet de transmettre la ligne de départ et le nombre de lignes à renvoyer par le serveur. Cette fonctionnalité offre un accès aux données plus efficace en n'extrayant que les lignes que vous devez afficher. Toutefois, elle lit toutes les lignes contenues dans la table, si bien que les appels consécutifs peuvent contenir des lignes issues de la page précédente en raison d'insertions ou des dernières pages suite à des suppressions. Par conséquent, cette méthode est plus performante avec des données relativement statiques.

Accès distant binaire des DataSets
La version 2.0 permet désormais de sérialiser les DataSets à l'aide d'un format binaire lors de l'utilisation de l'accès distant .NET. Cette amélioration augmente les performances d'accès distant aux données entre les applications .NET, tout en réduisant le nombre d'octets transférés.

Transfert des objets DataSet et DataReader
Dans la version 1.1, vous ne pouviez charger un DataSet qu'à partir d'un objet DataAdapter. Dans la version 2.0, vous pouvez également en charger un directement à l'aide d'un objet DataReader et de la méthode Load. À l'inverse, vous pouvez désormais générer une classe DataTableReader (héritée de DbDataReader) avec la méthode GetDataReader afin de faire défiler le contenu d'un DataSet. Cette fonctionnalité facilite le chargement d'un DataSet et la consultation de ses données.

Yukon

Cette catégorie rassemble les nouvelles fonctionnalités d'ADO.NET 2.0 qui se rapportent directement à la nouvelle version du code SQL Server nommé Yukon, attendu à la même époque.

MARS

La fonctionnalité MARS (multiples jeux de résultats actifs) vous permet d'utiliser plusieurs jeux de résultats simultanément sur une même connexion à Yukon. Cela peut s'avérer utile si vous devez ouvrir une classe SqlDataReader et, pendant le défilement, exécuter une commande sur une ligne donnée. MARS permet aux deux commandes de partager le même objet SqlConnection, si bien qu'une seconde connexion à SQL Server devient superflue.

Notification des modifications

L'une des nouvelles fonctionnalités les plus intéressantes de Yukon est sa faculté à supporter les notifications. ADO.NET 2.0 inclut le support par programmation de cette fonctionnalité en incluant un objet SqlNotificationRequest qui peut être lié à une commande SqlCommand.

Lorsque les données renvoyées par la commande changent dans la base de données, un message est envoyé dans la file d'attente de notification spécifiée. Le code ADO.NET peut alors interroger la file d'attente, soit en utilisant une requête asynchrone qui bloque jusqu'à l'envoi d'un message, soit en vérifiant régulièrement la file d'attente avec la nouvelle syntaxe Transact-SQL.

Pour faciliter davantage encore l'utilisation de cette fonctionnalité, une classe SqlDependency qui paramètre un délégué asynchrone est incluse. Elle sera appelée lors d'une modification des données et peut être utilisée conjointement avec le moteur de mise en mémoire cache ASP.NET, à l'instar des autres dépendances.

Types Yukon

ADO.NET 2.0 supporte le jeu complet de types de données Yukon, notamment XML et les types définis par l'utilisateur (UDT). Cela signifie que les colonnes dans Yukon définies en tant que XML peuvent être extraites en tant qu'objets XmlReader et que les UDT peuvent être transmis aux procédures stockées et renvoyés par les requêtes en tant que types .NET standard. Vos applications peuvent ainsi exploiter les données en tant qu'objets entièrement formés, tout en interagissant avec la base de données utilisant les objets. Cette fonctionnalité peut être mise à profit lors de la rédaction de code géré s'exécutant en cours de processus dans SQL Server, ce qui permet à la fois à la procédure stockée gérée et au code client d'utiliser le même type .NET.

Curseurs côté serveur

Comme ils ont souvent entraîné une dégradation des performances des applications, les curseurs côté serveur des versions 1.0 et 1.1 d'ADO.NET ont été abandonnés dans ADO 2.x. Mais ADO.NET 2.0 réintroduit le concept dans Yukon à l'aide des méthodes ExecuteResultset et ExecuteRow de l'objet SqlCommand et de la classe SqlResultset.

La classe SqlResultset offre un curseur flottant et actualisable qui peut être utile pour les applications qui doivent consulter une grande quantité de données mais ne mettre à jour que quelques lignes. Bien que cette fonctionnalité puisse être utilisée à partir d'applications clientes telles qu'ASP.NET, elle est principalement destinée à être utilisée lors de l'écriture de code géré s'exécutant en cours de processus avec Yukon sous la forme de procédures stockées.

Copie en masse

Bien qu'il ne s'agisse pas d'une particularité Yukon, ADO.NET 2.0 permet à présent d'accéder par programmation au programme BCP ou API de copie en masse exposée par SQL Server. Pour ce faire, il faut utiliser les classes SqlBulkCopyOperation et SqlBulkCopyColumnAssociator du namespace System.Data.SqlClient.

Et ce n'est qu'un début... Mes descriptions des nouvelles fonctionnalités d'ADO.NET 2.0 sont basées sur ce que j'ai pu voir dans la version alpha. Bien entendu, les choses sont susceptibles d'évoluer d'ici la première version bêta, prévue au printemps.