Difference between revisions of "SQLdb Tutorial4/fr"
| Line 8: | Line 8: | ||
== Pourquoi utiliser des modules de données ? == | == Pourquoi utiliser des modules de données ? == | ||
| − | + | C'est simple - après avoir suivi les tutoriels de Lazarus : | |
| − | * [[SQLdb Tutorial0]] | + | * [[SQLdb Tutorial0/fr|Tutoriel 0 SQLdb]] |
| − | * [[SQLdb Tutorial1]] | + | * [[SQLdb Tutorial1/fr|Tutoriel 1 SQLdb]] |
| − | * [[SQLdb Tutorial2]] | + | * [[SQLdb Tutorial2/fr|Tutoriel 2 SQLdb]] |
| − | * [[SQLdb Tutorial3]] | + | * [[SQLdb Tutorial3/fr|Tutoriel 3 SQLdb]] |
| − | + | 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 == | == Commençons == | ||
Revision as of 07:09, 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
In the Lazarus IDE, create a new Application and then click File --> New --> Data Module
You will be presented with a window as if you selected 'New Form':
The difference is this window/form will only accept non-visual components. In fact, look at your Component Palette: it has been greatly reduced to only allow selection of ONLY non-visual components.
Chacun a sa propre façon de faire
Your use of data modules will vary to suit your own needs. but as an example, I have at least 2 data modules:
Unit: DataModule1 On this module I 'drop' a T*Connection and a TSQLTransaction.
DataModule1 is used as the connection for all queries.
I then create a DataModuleN for each table or view.
Each DataModuleN will need to have the DataModule1 unit (unit2 in this example) added to the USES clause to connect to the database.
From here everything is the same as stated in SQLdb Tutorial1. The components are connected in the same way and access is identical.
Plus d'utilisations des modules de données
Additional components
In this example, DataModule1 had nothing more than a Connection and Transaction, but in a 'real' application, this container would typically also hold global non-visual components to be used by the application.
For example, Load and Save INI settings, TOpenDialog, TSaveDialog, etc. The concept here is to isolate data access from the business logic of an application. A change in data source for any application is never a minimal task, but having the datasources isolated will make the change much easier.
Débogage
Debugging a program is also a difficult task. By separating data access and business logic, the code to be viewed is halved. Data access and business logic can be tested separately to at least halve the problem.
The importance of the DataModule will become even more obvious when developing other applications using the same database and tables. The data module can of course be reused in the new 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
