> Tech > L’ère .NET

L’ère .NET

Tech - Par iTPro - Publié le 24 juin 2010
email

Quand elle a commencé à  concevoir le .NET Framework, Microsoft en a profité pour revoir et améliorer le modèle d'accès aux données. Plutôt que d'étendre davantage ADO, Microsoft a décidé de concevoir un nouveau framework d'accès aux données - tout en gardant le sigle ADO. Microsoft a conçu ADO.NET en

L’ère .NET

profitant de son expérience
avec son modèle objet ADO.
Mais, par rapport à  ADO, ADO.NET répond
à  trois besoins importants : fournir
un modèle d’accès aux données
déconnecté, indispensable pour
l’environnement Web ; assurer l’intégration
étroite avec XML ; et offrir l’intégration
sans couture avec le .NET
Framework (compatibilité avec le
système type de la bibliothèque de
classes de base, par exemple).

Architecture d’ADO.NET. L’objet Recordset, qui effectue tant de
fonctions dans ADO, n’est plus là . A sa
place, ADO.NET a plusieurs objets
voués à  des tâches spécifiques. Le tableau
1 décrit trois de ces objets dédiés
: DataAdapter, DataReader et
DataSet.

Fournisseurs de données .NET. Le
fournisseur de données .NET est un composant
essentiel d’ADO.NET dont il met
en oeuvre les interfaces. Ainsi, un fournisseur
de données .NET créera l’objet
DataReader afin que votre application ou
l’objet DataSet puisse l’utiliser.

Un fournisseur de données
contient quatre objets principaux :
Connection, pour se connecter à  une
source de données ; Command, qui
exécute des commandes sur une
source de données ; DataReader, qui lit
des données provenant d’une source
de données en mode connecté lecture
seule, et retransmission seule ; et
DataAdapter, qui lit les données provenant
d’une source et les utilise pour
remplir l’objet DataSet.

Visual Studio .NET inclut deux
fournisseurs de données .NET. Le fournisseur
de données SQL Server .NET
sert à  se connecter à  des bases de données
SQL Server 7.0 et ultérieures.
Cette méthode d’accès est plus efficace si l’on utilise SQL Server 7.0 et ultérieures
parce que le fournisseur de
données SQL Server .NET communique
directement avec SQL Server par
l’intermédiaire du protocole TDS
(Tabular Data Stream). Le fournisseur
de données OLE DB .NET sert à  se
connecter à  des bases de données non-
SQL Server, comme Oracle ou IBM
DB2. Ce fournisseur de données utilise
le fournisseur OLE DB pour les bases
de données respectives.

A l’heure qu’il est, Microsoft vient
juste de lancer un fournisseur de données
tiers pour .NET – l’ODBC .NET
Data Provider – Release Candidate
Beta. On peut télécharger ce fournisseur
de données à  partir du site Microsoft à  http://www.microsoft.
com/data/download_odbcnetrc.htm.

Pour choisir
un chemin, le premier facteur à 
prendre en compte est quel fournisseur
de données .NET on doit utiliser. Si l’on utilise SQL Server 7.0 ou plus récent,
il est judicieux d’utiliser le fournisseur
de données SQL Server .NET. Si
la base de données est SQL Server 6.5
ou toute autre base de données non-
SQL Server qui accompagne un fournisseur
OLE DB (Oracle, par exemple),
on utilisera le fournisseur de données
OLE DB .NET. Notons que l’on peut quand même utiliser le fournisseur de
données OLE DB .NET même avec SQL
Server 7.0 et ultérieur, mais on perdra
l’avantage, du point de vue des performances,
de communiquer directement
avec SQL Server par l’intermédiaire de
TDS. Toutefois, ce chemin non spécifique
présente l’avantage de la portabilité
: on peut utiliser des bases de données
différentes sans modifier le code.

Ensuite, il faut déterminer les
tâches à  exécuter. S’il s’agit simplement
de lire et d’afficher les données
provenant d’une source, l’objet
DataReader suffit probablement. Mais,
s’il faut manipuler les données (pour
les modifier ou les supprimer), il
vaut mieux utiliser l’objet DataSet.
N’utilisez DataSet que si c’est vraiment
nécessaire, parce DataSet est, par nature,
plus lent que DataReader.
(DataSet utilise DataReader pour
peupler sa table.)

Téléchargez gratuitement cette ressource

Comment sécuriser la Digital Workplace ?

Comment sécuriser la Digital Workplace ?

Avec le recours généralisé au télétravail, les entreprises ont ouvert davantage leur SI. En dépit des précautions prises, elles ont mécaniquement élargi leur surface d’exposition aux risques. Découvrez 5 axes à ne pas négliger dans ce Top 5 Sécurité du Télétravail.

Tech - Par iTPro - Publié le 24 juin 2010