Datalib : simplifiez-vous la vie avec ado.net
Description
En général, programmer ADO.NET n'a rien de difficile. Mais à force de repéter tout le temps les mêmes gestes, on fini par se lasser un peu.
La bibliothèque DataLib comporte des classes qui prennent automatiquement en charge l'accomplissement d'un certain nombre de tâches quand on travaille avec ADO.NET.
Les habitués de Java reconnaîtront certainement un certain nombre de similitudes avec l'API commons.dbutils. C'est que je me suis légèrement inspiré de cette dernière. Mais .NET n'étant pas Java, j'ai dû faire quelques ajouts pour tirer pleinement profit des avantages de la plate-forme .NET.
Dans la DataLib, vous trouverez principalement une classe nommée QueryRunner. Elle permet d'exécuter des commandes SQL sur une source de données ADO.NET et de recupérer le resultat sous la forme voulue. La transformation du resultat est assurée par un IDataReaderHandler à transmettre en paramètre à la méthode de QueryRunner que vous invoquez. DataLib contient huit implémentations de l'interface IDataReaderHandler et vous pouvez en ajouter. QueryRunner permet également de préparer un commande SQL en vue d'une exécution en boucle avec des valeurs de paramètres variables.
Vous y trouverez aussi une classe nommée DataSetManager qui encapsule un DataSet et fourni des méthodes pour le chargement, l'actualisation et la mise à jour des données du DataSet.
DataSetManager utilise très souvent DbObjectsFactory pour créer par reflexion certains objets nécessaires à la gestion du DataSet interne. Comme DataSetManager hérite de QueryRunner, il vous permet également d'attaquer directement la BDD sans passer par le DataSet.
Toutes ces classes peuvent travailler indifféremment avec n'importe quel fournisseur de données; célà vous dispense de devoir modifier votre code dès que vous changez de fournisseur de données. Mais pour que la portabilité soit parfaite, il faudrait que la syntaxe de vos requêtes SQL ne pose pas de problème en cas de changement de fournisseur. Comme solution, DataLib propose la classe QueryLoader dont le rôle est de charger vos requête à partir d'un fichier texte et de les invoquer par nom(les requêtes étant écrites dans le fichier sous-forme : nom = code sql;). Comme ça, à chaque changement de fournisseur, vous n'avez qu'à reéditer votre fichier de requêtes.
Bonne programmation et merci d'avance pour vos remarques et suggestions.
Le code n'a pas été commenté mais célà viendra. La demo fournie est basée sur une base PostgreSQL mais il est facile de l'adapter à une base Access. Les classes DataSetManager et QueryLoader ne sont pas exploitées dans la demo. Une prochaîne mise à jour devrait présenter une démo plus complète.
La bibliothèque DataLib comporte des classes qui prennent automatiquement en charge l'accomplissement d'un certain nombre de tâches quand on travaille avec ADO.NET.
Les habitués de Java reconnaîtront certainement un certain nombre de similitudes avec l'API commons.dbutils. C'est que je me suis légèrement inspiré de cette dernière. Mais .NET n'étant pas Java, j'ai dû faire quelques ajouts pour tirer pleinement profit des avantages de la plate-forme .NET.
Dans la DataLib, vous trouverez principalement une classe nommée QueryRunner. Elle permet d'exécuter des commandes SQL sur une source de données ADO.NET et de recupérer le resultat sous la forme voulue. La transformation du resultat est assurée par un IDataReaderHandler à transmettre en paramètre à la méthode de QueryRunner que vous invoquez. DataLib contient huit implémentations de l'interface IDataReaderHandler et vous pouvez en ajouter. QueryRunner permet également de préparer un commande SQL en vue d'une exécution en boucle avec des valeurs de paramètres variables.
Vous y trouverez aussi une classe nommée DataSetManager qui encapsule un DataSet et fourni des méthodes pour le chargement, l'actualisation et la mise à jour des données du DataSet.
DataSetManager utilise très souvent DbObjectsFactory pour créer par reflexion certains objets nécessaires à la gestion du DataSet interne. Comme DataSetManager hérite de QueryRunner, il vous permet également d'attaquer directement la BDD sans passer par le DataSet.
Toutes ces classes peuvent travailler indifféremment avec n'importe quel fournisseur de données; célà vous dispense de devoir modifier votre code dès que vous changez de fournisseur de données. Mais pour que la portabilité soit parfaite, il faudrait que la syntaxe de vos requêtes SQL ne pose pas de problème en cas de changement de fournisseur. Comme solution, DataLib propose la classe QueryLoader dont le rôle est de charger vos requête à partir d'un fichier texte et de les invoquer par nom(les requêtes étant écrites dans le fichier sous-forme : nom = code sql;). Comme ça, à chaque changement de fournisseur, vous n'avez qu'à reéditer votre fichier de requêtes.
Bonne programmation et merci d'avance pour vos remarques et suggestions.
Source / Exemple :
Voir le ZIP
Conclusion :
Le code n'a pas été commenté mais célà viendra. La demo fournie est basée sur une base PostgreSQL mais il est facile de l'adapter à une base Access. Les classes DataSetManager et QueryLoader ne sont pas exploitées dans la demo. Une prochaîne mise à jour devrait présenter une démo plus complète.
Codes Sources
A voir également
- Datalib : simplifiez-vous la vie avec ado.net
- Datalib essais - Forum VB.NET
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.