Discussion :

[BeanzMaster]

Re-Bonjour

J'ai une deuxième question sur le livebinding en runtime et le remplissage depuis une liste de données provenant d'une BDD. Depuis que j'ai reçu le livre de Cary Jensen "Delphi in Depth : FireDac" je comprend mieux certaine choses (et je n'ai pas encore fini de le lire , mais je n'ai pas encore eu le déclic en ce qui concerne l'utilisation du TFDUpdateSQL. Ca va venir )
Pour mon projet professionnel j'ai besoin de gérer des tables de données (MySQL, SQLLite et exportation vers JSON). Je dois concevoir deux applications. Une pour Desktop et l'autre pour Mobile. Ces deux applications seront amener à manipuler ces tables de données. A l'heure actuelle j'ai trouvé une solution qui me convient pour la manipulation des BDD avec une approche "MVC" dans les grandes lignes et qui me permet d'avoir une structure réutilisable.

Pour l'affichage des données (pour le moment) j'utilise un TListView que je rempli en runtime comme ceci (version simplifiée)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
function TDBClientController.GetAllItems(aList: TClientModelList) : Integer;
Var
  LData : TClientDataModel;
begin
  Result := -1;
  if aList = nil then exit;
  FFDQuery.SQL.Clear;
  FFDQuery.SQL.Add('SELECT ID, FirstName, LastName, EMail, GenderID FROM '+ cTableName); // + 'ORDER BY FirstName ASC');
  Try
    FFDQuery.Open();
    while not(FFDQuery.Eof) do
    begin
      LData.ID := FFDQuery.FieldByName('ID').AsInteger;
      LData.FirstName := FFDQuery.FieldByName('FirstName').AsString;
      LData.LastName := FFDQuery.FieldByName('LastName').AsString;
      LData.EMail := FFDQuery.FieldByName('EMail').AsString;
      LData.GenderID := FFDQuery.FieldByName('GenderID').AsInteger;
      aList.Add(LData);
      FFDQuery.Next;
    end;
  Finally
    Result := FFDQuery.RecordCount;
    FFDQuery.Close;
  End;
end;
 
procedure TDBClientView.RefreshList;
var
  LDataList : TClientModelList;
  LData : TClientDataModel;
  Litem: TListViewItem;
begin
  LDataList := TClientModelList.Create;
  if FOwner.GetAllItems(LDataList) > -1 then
  begin
    Try
      FListView.Items.Clear;
      for LData in LDataList do
      begin
        LItem := FListView.Items.Add;
        LItem.Tag := LData.ID;
        LItem.Objects.FindObjectT<TListItemText>('FirstName').Text := LData.FirstName;
        LItem.Objects.FindObjectT<TListItemText>('LastName').Text := LData.LastName;
        LItem.Objects.FindObjectT<TListItemText>('EMail').Text := LData.EMail;
      end;
    Finally
      FreeAndNil(LDataList);
    End;
  end;
end;

Ma question est la suivante à la place de remplir le ListView est-ce possible de remplir un TBindSourceDB en runtime automatiquement en le liant au FFDQuery ou dois-je avoir un "FDQuerySelect" toujours actif et le lier simplement ?
Ou dois-je passer par un TPrototypeBindSource et/ou TAdapterBindSource. Quelle serait selon vous la meilleure méthode ?

(j'espère que j'ai été assez clair dans ce que je souhaite réaliser)

D'avance merci de vos conseils

[SergioMaster]

Bonjour,

la méthode simple : lier directement la requête sans passer par la POO
la méthode POO (tuto en cours de rédaction) passer par un TPrototypeBind source ou ,si l'on veut s'affranchir des générateurs et de la conception visuelle de lien, le simple AdaptaterBindSource peu suffire mais créer les liens au runtime oui c'est possible (toujours dans le même tuto ) .
Le truc c'est que les liaisons POO au runtime le meilleur truc c'est de voir comment le lien a été fait dans le fmx c'est un peu le serpent qui se mord la queue ou alors avoir des bons petits morceaux de codes prêts à l'emploi.

l'explication de la technique est, je crois que c'est le bon, dans ce blog

[BeanzMaster]

Re bonjour Serge

Bonjour,

la méthode simple : lier directement la requête sans passer par la POO

Je ne vois pas ce que tu veux dire par là. Lier simplement le Query au BindSourceDB dans mon "FormCreate" ?

la méthode POO (tuto en cours de rédaction) passer par un TPrototypeBind source ou ,si l'on veut s'affranchir des générateurs et de la conception visuelle de lien, le simple AdaptaterBindSource peu suffire mais créer les liens au runtime oui c'est possible (toujours dans le même tuto ) .
Le truc c'est que les liaisons POO au runtime le meilleur truc c'est de voir comment le lien a été fait dans le fmx c'est un peu le serpent qui se mord la queue ou alors avoir des bons petits morceaux de codes prêts à l'emploi.

C'est pas gagner d'aller voir dans le code de FMX Je crois que je vais zyeuté du coté du forum Privé plus souvent

l'explication de la technique est, je crois que c'est le bon, dans ce blog

[/QUOTE]

J'ai justement la vidéo dans un onglet, que je regarderai un peu plus tard.

Sinon par rapport à ma structure de pseudo MVC

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
Type
  TClientDataModel = record
    ID        : Integer;
    FirstName : String[40];
    LastName  : String[40];
    EMail     : String[40];
    GenderID  : Integer;
  end;
 
  TClientModelList = TList<TClientDataModel>;
 
Type
  IDBClientCrudAdapter = Interface
    ['{FD7F097F-ACB7-45A8-A1B9-A40D57714D80}']
    function CreateTable : Boolean;
    function GetNewID : Integer;
    function CreateItem(aValue : TClientDataModel) : Integer;
    function ReadItem(anId : Integer; out aValue : TClientDataModel) : Boolean;
    function UpdateItem(aValue : TClientDataModel) : Boolean;
    function DeleteItem(anId: Integer):Boolean;
    function GetAllItems(aList : TClientModelList) : Integer;
  end;
 
  TDBClientController  = class;
  TDBClientView = class
  private
    FListView : TListView;
    [weak] FOwner : TDBClientController;
 
    FOnDeleteListItem : TListViewBase.TDeleteItemEvent;
    FOnSelectListItem : TListViewBase.TListItemEvent;
 
  protected
    procedure DoListViewItemClick(const Sender: TObject; const AItem: TListViewItem);
    procedure DoListViewDeleteItem(Sender: TObject; AIndex: Integer);
  public
 
    Constructor Create(aOwner : TDBClientController);
    Destructor Destroy; override;
 
    procedure SetListView(aListView : TListView);
 
    procedure RefreshList;
 
    property OnDeleteListItem :TListViewBase.TDeleteItemEvent Read FOnDeleteListItem Write FOnDeleteListItem;
    property OnSelectListItem : TListViewBase.TListItemEvent Read  FOnSelectListItem Write FOnSelectListItem;
  end;
 
  TDBClientController  = Class(TInterfacedObject, IDBClientCrudAdapter)
  private
    Const
      cTableName : String = 'bnz_clients';
      cCreateTableSQL = 'CREATE TABLE IF NOT EXISTS bnz_clients ('
                      + 'ID INTEGER NOT NULL PRIMARY KEY,'
                      + 'FirstName TEXT, LastName TEXT, EMail TEXT,'
                      + 'GenderID INTEGER)';
  private
    FView : TDBClientView;
    FFDQuery : TFDQuery;
    FFDConnection : TFDConnection;
 
    FOnCreateNewItem : TNotifyEvent;
    FOnUpdateItem : TNotifyEvent;
    FOnDeleteItem : TNotifyEvent;
    FOnReadItem : TNotifyEvent;
 
    function GetCurrentID: Integer;
    procedure SetCurrentID(const Value: Integer);
 
 
  protected
    FCurrentID : Integer;
 
    function GetNewID : Integer;
//    procedure DoOnDeleteListItem(Sender: TObject; AIndex: Integer);
//    procedure DoOnSelectListItem(const Sender: TObject; const AItem: TListViewItem);
 
  public
 
    Constructor Create(aConnection : TFDConnection);
    Destructor Destroy; override;
 
    function CreateTable : Boolean;
    function CreateItem(aValue : TClientDataModel) : Integer;
    function ReadItem(anId : Integer; out aValue : TClientDataModel) : Boolean;
    function UpdateItem(aValue : TClientDataModel) : Boolean;
    function DeleteItem(anId: Integer):Boolean;
    function GetAllItems(aList : TClientModelList) : Integer;
 
    property Connection : TFDConnection Read FFDConnection Write FFDConnection;
    property View : TDBClientView Read FView;
    property CurrentID : Integer Read GetCurrentID Write SetCurrentID;
  end;

j'ai également trouvé ce billet de Malcom Groves qui passe par un TAdapterBindSource.

Je vais tester les différentes solutions et voir ce qui serait le mieux.

Merci

[SergioMaster]

Je ne vois pas ce que tu veux dire par là.

j'avoue ma ta question n'est pas très claire non plus pourquoi passer par des listes d'objets "that is my question"

C'est pas gagner d'aller voir dans le code de FMX

je te le fais pas écrire mais c'est pas si compliqué dans des projets simples

J'ai justement la vidéo dans un onglet, que je regarderai un peu plus tard.

était-ce la bonne donc !

je ne vais pas critiquer ton modèle juste que j'ai du mal à comprendre (à cause de l'âge et de mon poil dans la main) que l'on veuille passer par des objets quand on a déjà les outils de FDQuery.
Je vais faire hurler mais la POO implique plus de code et donc qui dit plus de code dit plus de risque (cela dit c'est très bien avec une approche ORM en utilisant TMS Aurelius)
Bon, enfin MVC, POO, ORM etc.. je fini par m'y perdre dans ces sigles

j'ai besoin de gérer des tables de données (MySQL, SQLLite et exportation vers JSON)

jusque là, je suis

Je dois concevoir deux applications. Une pour Desktop et l'autre pour Mobile. Ces deux applications seront amener à manipuler ces tables de données

là encore je ne suis pas perdu

pour la manipulation des BDD avec une approche "MVC" dans les grandes lignes et qui me permet d'avoir une structure réutilisable.

là c'est un peu plus glissant : être obligé de charger les données dans une liste d'objets hum , pourquoi pas une table mémoire (fdmemtable) ?
Pour l'instant tu n'as qu'une seule table, mais comment vas tu gérer tes listes si tu as plusieurs tables dans un contexte maitre détail par exemple ? Je ne dis pas que c'est pas possible encore une fois le futur tutoriel mais avec beaucoup de tables impliquées... ça devient vite galère

je n'ai pas encore eu le déclic en ce qui concerne l'utilisation du TFDUpdateSQL.

dés qu'une requête va contenir des jointures tu va vite t'y mettre

j'ai également trouvé ce billet de Malcom Groves qui passe par un TAdapterBindSource

.
presque tout est dans cette partie de code

Code :

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

1
2
3
4
5
6
procedure TForm4.AdapterBindSource1CreateAdapter(Sender: TObject;
  var ABindSourceAdapter: TBindSourceAdapter);
begin
  MyPerson := TPerson.Create('Fred', 'Flintstone', 40);
  ABindSourceAdapter := TObjectBindSourceAdapter.Create(self, MyPerson, True);
end;

à un détail près quand il s'agit d'une liste d'objets

Code :

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

ABindSourceAdapter:=TListBindSourceAdapter<TClientDataModel>.Create(self,aListeClients, True);

[BeanzMaster]

était-ce la bonne donc !

Oui c'est la bonne.

j'avoue ma ta question n'est pas très claire non plus pourquoi passer par des listes d'objets "that is my question"
...
je ne vais pas critiquer ton modèle juste que j'ai du mal à comprendre (à cause de l'âge et de mon poil dans la main) que l'on veuille passer par des objets quand on a déjà les outils de FDQuery.
Je vais faire hurler mais la POO implique plus de code et donc qui dit plus de code dit plus de risque (cela dit c'est très bien avec une approche ORM en utilisant TMS Aurelius)
Bon, enfin MVC, POO, ORM etc.. je fini par m'y perdre dans ces sigles

Tes critiques sont constructives ! et les BDD et Delphi, est un sujet sur lequel j'ai peu d'expérience.

Pour répondre à "pourquoi passer par des listes d'objets ?" J'ai fais ce choix , par rapport à mon expérience avec PHP par rapport à la gestion des BDD ou j'utilise un système d'ORM assez rapide et simple à mettre en place (un table = une classe et une fonction "addrelation", et les procedures pour gérer tout ça se font par des fonctions de bases qui sont adaptés par réfactoring, bref tout une autre histoire et une autre façon de programmer....)
Je suis partie dans cette direction pour pouvoir simplement réutiliser ces objets dans plusieurs applications, pour ne pas avoir à faire des copier coller à tout va.
J'ai tenté de passer par des solutions ORM, mais c'est complexe à mettre en place et chaque solutions/package que j'ai trouvé ont leur propre méthodes de mise en place et c'est un peu déconcertant à comprendre. Et je pense que cela sert à rien de les utiliser si je ne maitrise pas les bases et le développement avec Firedac.

là c'est un peu plus glissant : être obligé de charger les données dans une liste d'objets hum , pourquoi pas une table mémoire (fdmemtable) ?
Pour l'instant tu n'as qu'une seule table, mais comment vas tu gérer tes listes si tu as plusieurs tables dans un contexte maitre détail par exemple ? Je ne dis pas que c'est pas possible encore une fois le futur tutoriel mais avec beaucoup de tables impliquées... ça devient vite galère

ah oui ! le TFDMemtable je n'y avais pas pensé. je vais y réfléchir. Je pourrais donc créer mes champs directement dedans.

Pour ce qui est de la gestion des listes cela ne me pose pas de réels problèmes pour le moment Elle sont dynamiques, non persistantes et juste utilisées pour faire le lien et remplir le "listview" à ce stade.
Pour ce qui est des relations, idem tout ce fait dans mes objets MVC. Tu as pu le voire il y a le champ "GenderID" avec la commande SQL "SELECT.....JOIN....." adapté il est facile (du moins dans ma tête) de récupérer la variable TEXT associé dans la table adequate De même il serait facile de récupérer tous les commentaires d'une article par exemples. Articles et commentaires seraient alors liés et gérés dans un seul objet (exemple une fonction getComment(ArticleID):TCommentsList; (ou comme tu me l'a suggéré un TFDMemtable)
Il faut que je creuse un peu tout ça.

En y pensant maintenant, je pourrais me passer de la fonction "GetAllItems" et juste manipuler le TFDQuery. Le Record et (la liste qui me semble être OPTIONNELLE maintenant) c'est juste un pont et une question de simplicité d'utilisation et pour éviter de manipuler le FDQuery dans le programme principal. (au final je trouve qu'il y a moins de risque de se tromper et si il y a une erreur elle est centralisée)
Comme plus haut dans ma réponse, j'y vois l'avantage de la réutilisation directe et simplement dans d'autres applications sans se soucier de la gestion de la BDD qui en découle et de réécrire la roue une deuxième fois.

dés qu'une requête va contenir des jointures tu va vite t'y mettre

Oui c'est ce que pensais (ex Article --> Liste de commentaires) bon ici, ca va encore il n'y a que deux tables. Mais par la suite ou dans ma modélisation j'ai jusqu'à cinq tables à lier, cela risque d'être primordiale de passer par un UpdateSQL surtout pour les insertions et les modifications .
Doucement mais sûrement j'arriverai à comprendre la méthode à mettre en place.

presque tout est dans cette partie de code

Code :

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

1
2
3
4
5
6
procedure TForm4.AdapterBindSource1CreateAdapter(Sender: TObject;
  var ABindSourceAdapter: TBindSourceAdapter);
begin
  MyPerson := TPerson.Create('Fred', 'Flintstone', 40);
  ABindSourceAdapter := TObjectBindSourceAdapter.Create(self, MyPerson, True);
end;

à un détail près quand il s'agit d'une liste d'objets

Code :

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

ABindSourceAdapter:=TListBindSourceAdapter<TClientDataModel>.Create(self,aListeClients, True);

Après toutes tes remarques constructives, du coup est-ce que je peux lui passer directement les résultats du FDQuery au BindSourceAdapter, ou puis je le lier dynamiquement a TBindSourceDB ?
Si non j'en reviens à ma structure "MVC" et j'ai juste à convertir mon Record en Class et garder ma liste générique ?

Merci encore d'avance de tes conseils

[SergioMaster]

Après toutes tes remarques constructives, du coup est-ce que je peux lui passer directement les résultats du FDQuery au BindSourceAdapter, ou puis je le lier dynamiquement a TBindSourceDB ?
Si non j'en reviens à ma structure "MVC" et j'ai juste à convertir mon Record en Class et garder ma liste générique ?

BindSourceAdapter pour les Objets
BindSourceDB pour des datasources (FDQuery renvoyant un esemble de données, FDmemtable, FDtable etc...)
De là à écrire lier dynamiquement un FDQuery à un BindSourceDB j'ai jamais essayé mais au runtime mais pourquoi pas BindSourceDB.DataSets:=FDQuery1ça devrait le faire, reste à voir s'il ne faut pas fermer des trucs avant

[Invité]

Depuis que j'ai reçu le livre de Cary Jensen "Delphi in Depth : FireDac" je comprend mieux certaine choses (et je n'ai pas encore fini de le lire

Désolé pour ce hors sujet, cela fait plusieurs fois que j'entends parler de ce livre, il semble intéressant.
Par contre, il ne semble être qu'en anglais. Il faut un bon niveau pour comprendre ?

[SergioMaster]

Désolé pour ce hors sujet, cela fait plusieurs fois que j'entends parler de ce livre, il semble intéressant.
Par contre, il ne semble être qu'en anglais. Il faut un bon niveau pour comprendre ?

Il ne semble pas il est en anglais. Un bon niveau ? non pas forcément un niveau suffisant cependant en programmation (programmation d'application avec BDD) et en Base de données est un plus
pour saisir toutes les nuances possibles.
J'ai présenté et fait une critique de ce livre ici