Discussion :

[RamDevTeam]

Bonjour,

Je cherche à avoir une méthode de dev qui me permet d'avoir un appli la plus maintenable possible et la plus évolutive possible. Je me pose donc la question suivant quand on utilise delphi :

Prenons le cas simplifié d'une gestion de client.

j'ai 2 possibilités:

Principe 1 :
- Définition d'une classe TClient (unité Client.pas)
Propriété publiées :
CodeClient
Raison Sociale
ClientDataset
etc...
méthodes :
Edit;
Delete;
Post;
etc...

- Définition d'un écran
l'écran étant appelé avec comme paramètre l'objet client à modifier
ou nil pour indiquer une création de nouveau client.

=> les requêtes SQL sont donc gérés par la class Tclient et donc inconnu de l'écran. par contre, une rubrique d'un client doit être défini 2 fois (écran + class) ce qui donne un double travail


Principe 2:
Pas de classe Tclient.
Définition d'un écran.
Gestion des données directement dans l'écran.
(exemple, clic sur Enregistrer, le bouton execute la requete UPDATE)

Le principe 2 me semble un peu plus rapide à mettre en place, mais en même temps j'ai l'impression que le principe 1 est peut-etre celui qu'il faut utiliser pour avoir à long terme une appli maintenable.

A votre avis, que faut-il priviligier et pourquoi ? Existe t'il une autre méthode plus correct ?

Merci.

[LadyWasky]

Je crois que chez Raize, ils ont déjà planchés sur cette problématique. Ils mette d'ailleurs à dispo et gratuitement un ensemble de composants "Buziness Rules"

va voir ici : http://www.dbmsmag.com/9611d18.html

bon courage

[TicTacToe]

Je donne mon point de vue

Un écran final présente à la fois des outils qui peuvent être génériques et à la fois des données spécifiques.
amha, il faut séparer le mieux possible ce qui est générique du spécifique pour ne se concentrer que sur la nouveauté spécifique et non sur les outils qui tournent autour et que l'on a déjà développés.

Pour ma part, mais ce n'est que mon avis, J'ai une form de base abstraite, puis des forms fiches + grilles abstraites egalement qui sont totalement indépendantes de la nature de la donnée finale et qui contiennent pas mal d'outils (export, edition etc...) mais aussi de gestion diverses (verrouillages, allocation etc...)

lorsque on ajoute un outils, (par exemple synthese d'une grille selon certains critère), il est intégré d'office dans toute l'appli.

ensuite, la form finale instanciée ne spécifie que la nouveauté et les actions spécifiques.

Voila, la grande ligne c'est utiliser l'heritage principalement pour les écrans (qui eux même contiennent base et composants et menu...).

Mais on pourrait en discuter des heures

[DMO]

Mon humble avis :

Je note que la question est posée dans le contexte spécifique d'une application base de données. Ma suggestion de réponse tient compte de cela.

En gros je dirais : oui pour les classes métier, mais pas une classe perso ne partant de rien (TObject). Dans le détail ça donne :

Chacun fait comme il le sent, mais les outils dont nous disposons sous Delphi pour développer des applications base de données peuvent effectivement nous permettre de tirer le meilleur de tes deux pistes :

• Les "écrans" ne contiennent aucun traitement métier (aucune requete, etc...). Ils ne sont réellement que l'interface graphique et de saisie de ton application. Pourquoi pas comme le suggère TicTacToe utiliser l'héritage de forms si cela est une solution pour toi aussi, je pense que c'est une bonne idée. Faut voir.
• Tous ces "écrans" contiennent pour l'affichage et la saisie/modification des données venant de la base uniquement des contrôles orientés données.
• Par l'intermédiaire des TDataSource, les "ecrans" sont liés au même DataModule (ou chacun à une instance différente c'est comme tu veux, mais je veux simplement dire : la même classe de DataModule). Je pense que l'idéal est que les TDataSource soient dans les datamodules. Mais je me laisserais peut-être un peu de liberté sur ce point (en prenant garde de correctement encapsuler les traitements métier dans les datamodules).
• Il y a par exemple un DataModule pour la gestion des clients, un pour la gestion du stock, ... Les DataModules sont véritablement tes classes métier, ils peuvent s'utiliser les uns les autres, tu peux aussi faire de l'héritage de datamodules si tu veux.

Voilà c'est ainsi que je ferais. Je concentrerais tous les traitements métier dans les datamodules, avec la granularité que tu juges idéale (un gros datamodule, plein de petits, un par theme, comme tu veux...)

Bon dev'

[RamDevTeam]

Je pense effectivement que ta solution est un bon compromis et j'été entrain de me pencher sur une orientation :
Tform = Affichage et interaction pur avec l'utilisateur..
DataModule = Méthode métier et interaction avec la base de donnée

J'arriverais donc au modèle suivant :
- un datamodule gérant la connexion à la BD, les droits d'accès
- un datamodule par domaine métier :
* Gestion des clients
* Gestion du stock
* etc ...
- Des écrans, utilisant ces datamodules.

Le point encore inconnu c'est le chemin que doivent emprunter les données pour les aller-retours entre le dataset et l'écran si on veut avoir la meilleur isolation métier/vue possible.

Tu parle des datasources. Si je veux que mon appli soit MDI. comment faire pour ouvrir dans 2 dossier client dans 2 fenêtres différentes.

- si le datasource est dans le datamodule, les 2 écrans pointent sur le même enregistrement.
- si le datasource est dans l'écran et le dataset dans le datamodule, c la même transaction qui est utilisée pour les 2 écrans, donc n'aurais je pas d'interférence sur l'écran 2 si je dois faire un rollback sur l'écran 1

- Est-ce que pour éviter tout ça, il ne faudrait pas :
*Soit, utiliser des dataset unidirectionnel type SQLQuery et faire soit-même ses requêtes SELECT, INSERT, UPDATE (ce qui implique de créer des objets "données" dans le datamodule). Le fonctionnement serait par exemple sur le OnShow du Tform :

Code :

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

1
2
3
4
5
6
7
   ObjClient := DMclient.GetCLientInfo(CodeClient, mdLockRecord);
   if ObjClient=nil then 
     // msg d'erreur et sortie
 
  // affichage .
  editX.text := ObjClient.RubriqueX;
  etc ..

Et pour l'enregistrement, evt OnClick du bouton Enrg.

Code :

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

1
2
3
4
ObjClient.Edit;
ObjClient.RubriqueX := EditX.text;
etc...
ObjClient.Post;

Inconvénient du système : Plus de boulot. Avantage : l'objet n'étant pas la table de la base de données, il permet de manipuler le vision une entité métier sans savoir si elle est scindé en X table ou issue d'une requete, d'une vue etc ...

* Soit, créer une instance du datamodule pour chaque écran client.

Qu'en pensez-vous ?

[DMO]

Je ferais ceci à ta place (encore une fois à adapter ou à ne pas suivre du tout en cas de désaccord, ce n'est qu'une suggestion) :

• Mettre les DataSource dans les ecrans.
• Bien brancher tous les contrôles bdd aux datasources.
• Adopter une convention de nommage cohérente (Exemples dsClient: TDataSource, tbClient: TIBTable, qrClient: TIBQuery, ...)
• Grâce à cette convention, créer une petite routine simple pour brancher une fiche et son datamodule (ca cherche sur la fiche tous les datasource et ca essaye de les brancher sur les datasets "de meme nom" dans le datamodule).
• Pour chaque fiche MDI, ajouter une composition du datamodule correspondant.
• Peu importe les composants utilisés et la façon de les utiliser, du moment que l'on ne viole pas l'encapsulation du datamodule depuis la fiche (Cf. code exemple ci-dessous) et que tout traitement métier (pour ainsi dire presque tout) est fait dans le datamodule.

Voilà, les fiches (les écrans) doivent pouvoir etre parfaitement remplacables.
On doit pouvoir utiliser les mêmes datamodules sans manquer de rien niveau fonctionnalités dans une autre application, une appli web par exemple.

Tu peux donc par exemple (ecrit rapido comme ca sans delphi) mettre des propriétés ou des méthodes à tes datamodules comme par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
TTypesClient = Set of (tcProfesionnel, tcParticulier);
 
TDMClient = class(TDataModule)
private
  (...)
public
  property TypesClient: TTypesClient read FTypesClient write SetTypesClient;
  procedure OuvrirConnexion; override;
end;

À utiliser en gros dans l'idée comme ça dans une fiche MDI un truc du genre :

Code :

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

1
2
3
4
5
6
7
8
procedure TFrmClient.FormShow(...);
begin
  FDMClient := TDMClient.Create(Self);
  LierFicheAuDataModule(Self, FDMClient);
  FDMClient.TypesClient := [tcProfesionnel, tcParticulier];
  FDMClient.OuvrirConnexion; 
// et non pas par exemple : FDMClient.DataBaseGestion.Connect;
end;

Ensuite bien sûr IHMment parlant dans la fiche tu peux modifier le type de client, ...

Je chercherais donc à avoir le moins possible de rafraichissements d'IHM explicites à faire, pour profiter le plus possible des facilités offertes par la gestion "standard" des bdd dans Delphi (donc non pas de "ObjClient" pour moi, mais juste le datamodule, et pas de "EditX.text :=" mais juste un TDBEdit et pas de code);

En gros moins je code, moins je crée de bugs (et donc mieux je me porte ).

Bon dev'