Difference between revisions of "SQLdb Tutorial4/fr"
| (3 intermediate revisions by the same user not shown) | |||
| Line 31: | Line 31: | ||
== Chacun a sa propre façon de faire == | == Chacun a sa propre façon de faire == | ||
| − | + | Votre utilisation des modules de données variera selon vos propres besoins. A titre d'exemple, j'ai au moins deux modules de données : | |
| − | + | Unité : DataModule1 | |
| − | + | Sur ce module, je pose ('drop') un ''T*Connection'' et un ''TSQLTransaction''. | |
[[file:conn.jpg]] | [[file:conn.jpg]] | ||
| − | DataModule1 | + | Le DataModule1 est utilisé comme connexion pour toutes les requêtes. |
| − | + | Je crée ensuite un module de données pour chaque table ou vue. | |
[[file:dm2.jpg]] | [[file:dm2.jpg]] | ||
| − | + | Chaque DataModuleN (unit2 dans cet exemple) nécessite d'avoir l'unité DataModule1 ajoutée dans sa clause use pour se connecter à la base de données. | |
| − | + | De là, tout est identique à ce qui est indiqué dans [[SQLdb Tutorial1/fr|Tutoriel SQLdb 1]]. Les composants sont connectés de la même manière et l'accès est identique. | |
== Plus d'utilisations des modules de données == | == Plus d'utilisations des modules de données == | ||
| − | === | + | === Composants supplémentaires === |
| − | + | Dans cet exemple, DataModule1 n'a rien d'autre qu'une connexion et une transaction, mais dans une application 'réelle', ce conteneur tiendra typiquement des composants non visuels globaux pour être utilisés dans l'application. | |
| − | + | Par exemple, enregistrer et sauvegarder des réglages dans une un ficher INI, ''TOpenDialog'', ''TSaveDialog'', etc. Le concept ici est d'isoler l'accès aux données de la logique métier d'une application. Une modification dans une source de données dans quelque application n'est jamais une petite tâche, mais l'isolation de la source de données rendra le changement plus simple. | |
=== Débogage === | === Débogage === | ||
| − | + | Le débogage d'un programme est une tâche difficile. en séparant l'accès aux données et la logique métier, le code à visualiser est réduit de moitié. L'accès aux données et la logique métier peuvent être testées séparément pour au moins diviser en deux le problème. | |
| − | + | L'importance des modules de données même plus évident quand on développera d'autres applications utilisant la même base de données et les mêmes tables. Le module de données peut être bien sûr réutilisé pour une nouvelle application. | |
== Voir aussi == | == Voir aussi == | ||
Latest revision as of 07:31, 4 April 2017
│
English (en) │
français (fr) │
日本語 (ja) │
Introduction
Ce tutoriel est une tentative de démonstration de l'emploi des Modules de données de Lazarus pour isoler les composants d'accès aux bases de données d'un projet de la logique associées aux accès. Une telle isolation rend la maintenance du programme et son débogage plus facile.
Le tutoriel a été développé en utilisant Windows 7 et SQLite3 comme base de données avec Lazarus 1.0.8 et FPC 2.6.2 ; toutefois, cela devrait fonctionner avec des versions antérieures. De la même façon, d'autres SGBD ou systèmes d'exploitation devraient nécessiter peu de modification, si jamais il y en a.
Pourquoi utiliser des modules de données ?
C'est simple - après avoir suivi les tutoriels de Lazarus :
développer une application 'réelle' devient plus difficile. 'Form1' grossit de manière exponentielle en gérant les différents événements et requêtes sur la base de données.
L'isolation de chaque accès aux tables dans un simple module de données rend le débogaqe et la maintenance plus simple. Une application peut avoir un nombre quelconque de modules de données - une petite application avec seulement une ou deux tables peut sans doute se satisfaire d'un seul module de données - une application plus ample pourrait probablement bénéficier de l'emploi d'un module de données pour chaque table ou vue.
L'exemple montré ici utilise juste deux tables avec de simples requêtes, mais cela peut être étendu pour intégrer plus d'options pour chaque table.
Commençons
Dans l'EDI de Lazarus, créez une nouvelle application et cliquez sur Fichier --> Nouveau --> Module de données.
Il vous sera présenté une fenêtre comme si vous aviez sélectionné 'Nouvelle fiche' !
La différence est que cette fenêtre/fiche n'accepte que des composants non visuels (pas seulement des composants liés aux base de données par ailleurs). En fait, jetez un oeil sur la palette : elle a été grandement réduite, elle ne permet plus que la sélection des composants non visuels.
Chacun a sa propre façon de faire
Votre utilisation des modules de données variera selon vos propres besoins. A titre d'exemple, j'ai au moins deux modules de données :
Unité : DataModule1 Sur ce module, je pose ('drop') un T*Connection et un TSQLTransaction.
Le DataModule1 est utilisé comme connexion pour toutes les requêtes.
Je crée ensuite un module de données pour chaque table ou vue.
Chaque DataModuleN (unit2 dans cet exemple) nécessite d'avoir l'unité DataModule1 ajoutée dans sa clause use pour se connecter à la base de données.
De là, tout est identique à ce qui est indiqué dans Tutoriel SQLdb 1. Les composants sont connectés de la même manière et l'accès est identique.
Plus d'utilisations des modules de données
Composants supplémentaires
Dans cet exemple, DataModule1 n'a rien d'autre qu'une connexion et une transaction, mais dans une application 'réelle', ce conteneur tiendra typiquement des composants non visuels globaux pour être utilisés dans l'application.
Par exemple, enregistrer et sauvegarder des réglages dans une un ficher INI, TOpenDialog, TSaveDialog, etc. Le concept ici est d'isoler l'accès aux données de la logique métier d'une application. Une modification dans une source de données dans quelque application n'est jamais une petite tâche, mais l'isolation de la source de données rendra le changement plus simple.
Débogage
Le débogage d'un programme est une tâche difficile. en séparant l'accès aux données et la logique métier, le code à visualiser est réduit de moitié. L'accès aux données et la logique métier peuvent être testées séparément pour au moins diviser en deux le problème.
L'importance des modules de données même plus évident quand on développera d'autres applications utilisant la même base de données et les mêmes tables. Le module de données peut être bien sûr réutilisé pour une nouvelle application.
Voir aussi
- SQLdb Tutorial0 : Instructions pour configurer les tables et les données d'exemple pour la série de tutoriels.
- SQLdb Tutorial1 : 1re partie de la série de tutoriels sur les bases de données, montrant comment configurer une grille pour afficher les données.
- SQLdb Tutorial2 : 2e partie de la série de tutoriels, montrant l'édition, l'insertion, etc.
- SQLdb Tutorial3 : 3e partie de la série de tutoriels, montrant comment développer pour des bases de données multiples et utiliser une fiche de connexion.
- SQLdb Tutorial4 : 4e partie de la série de tutoriels, montrant comment utiliser les modules de données.
- Vue d'ensemble des bases de données pour Lazarus : Information sur les bases de données supportées par Lazarus. Redirige vers des notes spécifiques à certaines bases de données.
- Paquet SQLdb : Information sur le paquetage SQLdb.
- Référence de programmation SQLdb : Une vue d'ensemble de l'interaction entre les composants de bases de données SQLdb.
- SqlDBHowto : Information sur l'utilisation du paquet SQLdb.
- Travailler avec TSQLQuery : Informations sur TSQLQuery.
- utilisation des paramètres
