Discussion :

[abdelghani_k]

Bonjour,

J'ai une base de données composée de plusieurs tables parmi :
articles, fournisseurs, receptions, lignes_reception, consommations, lignes_cons, centres_couts.

J'ai commencé à implémenter mon application qui contient un datamodule avec des ADOQuery et des fiches pour la mise à jour des tables.

Je veux implémenter un système basé sur des DLL. Pas besoin de compiler le tout et avoir un seul exécutable.
La màj de chaque table se fait par une dll ? mais comment ?
est ce quelq'un a une idée sur cette décomposition en dll avec un datamodule ?

Merci d'avance.

[Aka Guymelef]

Bonjour,

à partir du moment où tu découpes ton application en DLL, tu met en place des boîtes noires pour les autres composants de ton application car une DLL ne peut qu'exporter explicitement des procédures ou fonctions.

Dès lors tu ne peux plus simplement te contenter d'inclure l'unité de ton DataModule et utiliser sa variable globale pour accéder aux composants, tu es obligé ou de mapper les fonctions exportées ou de faire des appels dynamique à ta DLL et de passer à travers ces dernières pour accéder au DataModule. Et encore c'est assez alambiqué d'un point de vue conception.

Une bonne conception avec DLL, je dirais que chaque DLL représente chaque table avec des procédures d'insertion/modification/suppression de lignes et des fonctions de sélections qui retourne des TADOQuery.

[ShaiLeTroll]

Quelle DB ? Quellle Lib ? Quel Driver ?

Pourquoi vouloir utiliser le DataModule ?
Il ne serait pas plus simple de faire une classe abstraite genre TTableManager, qui serait surchargé dans le code de chaque DLL ...

Ensuite, les majs de quoi ? lors des changements de version ? ne serait-il pas plus simple d'avoir un XML qui décrit la base, et une classe qui utilise ce XML pour générer un SQL de ALTER

Les Majs ? les UPDATE de données ? Si tu sépares trop tes tables des unes et des autres, fait attention à ne pas te priver du relationnel ...

Ne voit pas les DLL comme une fin en soi ! Tu veux plutôt concevoir un modèle objet, chaque classe se chargeant des interactions avec la DB ... recherche sur le Web et sur le Forum, les notions de Persistance (InstantObjects, ECO, le modèle de phplive, ...) d'abstraction objet, ...

[abdelghani_k]

Pourquoi vouloir utiliser le DataModule ?
Il ne serait pas plus simple de faire une classe abstraite genre TTableManager, qui serait surchargé dans le code de chaque DLL ...

Est ce je peux avoir un exmple TTableManager ?

[ShaiLeTroll]

Un Exemple ? Je n'ai pas d'exemple, ce n'est qu'un concept, tu n'as même pas répondu à mes questions sur le type de DB !
Es-tu aller lire les liens que j'ai fourni ...
Regarde aussi les libs que j'ai cité comme InstantObjects, ...
Tu veux faire une modélisation Objet d'une DB, c'est une conception et une réalisation de haut niveau !
En quel delphi es-tu ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
TTableManager = class(TObject)
private
  function InternalMajStruct(const TableName: string); // Ici le vrai Code !
  function Intertal..
public
  function MajStruct; virtual; abstract;
  function Select: TDataSet; virtual; abstract;
  function Update: Boolean; virtual; abstract;
  ....

Tu dois faire ensuite l'implémentation,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
TTableManagerArticle = class(TTableManager)
public
  function MajStruct; override; // tu fais tes ALTER ou tu modifies FieldDefs, tu utilise dedans les Internal ... ou un méthode spécifique pour l'occasion !
  function Select: TDataSet; override; // tu fais un SELECT en SQL ou un filter 
  function Update: Boolean; override; // Bon ça devient plus complexe, que passé en paramètre, un SQL, un DataSet modifié ? ...
  property Fournisseurs: TTableRelationArticleFournisseur; // ah ah ! ça devient interessant !
...

Tient, ce sujet ne concerne pas la DB, mais un des fichiers texte, mais le principe de modélisation reste valable ... cela te laisse imaginer le code à produire, bien plus conséquent que via des simples TQuery laché sur un DataModule ...

[abdelghani_k]

Quelle DB ? Quellle Lib ? Quel Driver ?
Pourquoi vouloir utiliser le DataModule ?

J'utilise SQL Server 2000.
ma connexion est avec ADOConnection qui utilise l'ODBC :
Microsoft OLE DB Provider for SQL Server.

Je veux utiliser DataModule tout simplement c'est une habitude et point de vue conception d'application c'est recommandée.

[ShaiLeTroll]

J'ai au début abusé de ce composant, avec Paradox\BDE c'est tellement plus pratique ... ensuite, je l'ai vite abandonné, avec IB préférant des objets encaspulant les préparations de requêtes pour les "habituels" et une instanciation dynamique pour les requêtes "occasionnelles" sans préparation permanente ...

Recommandée ? Ah !
Ce n'est pas mon avis, j'ai trop vu des DataModule recouvert de plus de 300 Composants, à part pour servir de container pour libérer un groupement de composant, à part ça, je n'en ai jamais vu l'intéret, ... il est vrai que Delpih est aimé pour son IDE, et combiner à des modèles de conception (Design Pattern) drivant les interractions entre les classes et instances de classes ... on peut arriver quand même à beau modèle objet à partir de TDataModule ...

Et enfin, on peut envisager d'aller plus loin, se servir de l'IDE pour la faciliter tout en agrémentant notre DataModule de tout un tas de fonction supplémentaire ... bien sur, tu as la Classe ancêtre qui reste générique avec quelques composants de Base comme la Connexion (attention à celà, une connexion par DLL ou une globale partagée ... ), ainsi qu'un composant TADODataSet par défaut
Ensuite dans les surcharges, tu modifieras les propriétés en DesignTime ou en RunTime pour "spécialiser" ton DataModule ...

Rien n'empeche de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TTableManager = class(TDataModule)

[Franck SORIANO]

J'utilise SQL Server 2000.

Dans ce cas, au lieu de mettre le code de manipulation des tables dans des DLL, pourquoi ne pas faire des procédures stockée ? Tu pourras les mettre à jour sans être obligé de recompiler ton exe...
Mais bon, personnellement recompiler un exe à chaque mise à jour ne m'a jamais perturbé...

ma connexion est avec ADOConnection qui utilise l'ODBC :
Microsoft OLE DB Provider for SQL Server.

Désolé, mais tu mélanges tout !
Il n'y a pas d'ODBC là dedans. Tu utilises ADO pour te connecter au serveur SQL via son provider OLEDB. Mais c'est bien la façon normale pour se connecter à un serveur SQL 2000.

Je veux utiliser DataModule tout simplement c'est une habitude et point de vue conception d'application c'est recommandée.

Ouais... Je dirais plutôt comme ShaiLeTroll. La première appli Delphi à laquelle j'ai participée avait été écrite de cette façon. Tu arrives vite à 300 composants dans ton Datamodule, et là tu maudis la personne qui a inventé les Datamodules (et le RAD au passage...).

Personellement, je préfère exécuter mes requêtes directement sur la connexion, sans utiliser le moindre composant supplémentaire.

Pour le cas où tu voudrais qu'en même utiliser des DLL, fait attention à les compiler en utilisant les packages d'exécution. Sinon le code de la VCL sera dupliqué dans chaque DLL. Si tu fais de nombreuses DLL, tu vas vite sentir ta douleur...