* * *

Author Topic: Just to confirm my approach  (Read 659 times)

egsuh

  • Full Member
  • ***
  • Posts: 171
Just to confirm my approach
« on: November 09, 2018, 07:35:54 am »
Hi,  I just want your ideas on my approach.  I wrote an application which uses several forms, and one datamodule.  Most of the forms have to access different datasets in the datamodule.
I did several trial and errors, and finally settled on following approach.

1) in each TForm definition module, I  add a TDataSet variable under public section.
2) And assign TDataSet object in the datamodule to the variable within "program" unit, before Application.Run, like following.

Code: Pascal  [Select]
  1. unit fselectproject_5;
  2.  
  3. interface
  4. uses
  5.    Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, ExtCtrlsl
  6.  
  7. type
  8.  
  9.    TfProjectChoice = class(TForm)
  10.       bbrnLogin: TBitBtn;
  11.       bbtnCancelLogin: TBitBtn;
  12.    private
  13.       procedure RefreshProjectList;
  14.  
  15.    public
  16.       uid: string;
  17.       DataSet: TDataSet;  // <==   this is TDataSet variable.
  18.  
  19.    end;
  20.  
  21. var
  22.    fProjectChoice: TfProjectChoice;
  23. ....
  24.  
  25.  
  26. //---------------
  27.  
  28. program aq01editor;
  29.  
  30. {$mode delphi}{$H+}
  31.  
  32. uses
  33.   {$IFDEF UNIX}{$IFDEF UseCThreads}
  34.   cthreads,
  35.   {$ENDIF}{$ENDIF}
  36.   Interfaces, // this includes the LCL widgetset
  37.   Forms,   fselectproject_5, daq_fb_5, ...  ;
  38.  
  39. {$R *.res}
  40.  
  41. begin
  42.   RequireDerivedFormResource:=True;
  43.   Application.Initialize;
  44.   Application.CreateForm(TAQFB4, AQFB4);
  45.   Application.CreateForm(TfProjectChoice, fProjectChoice);
  46.   Application.CreateForm(TfQEdit, fQEdit);
  47.   Application.CreateForm(TfoNewQDef, foNewQDef);
  48.  
  49.   fProjectChoice.DataSet := AQFB4.dsProjects;   // <== Assign the dataset here.
  50.  
  51.   Application.Run;
  52. end.
  53.  

In this way, I can use the forms and datamodule almost independently. Up to now this works fine, without any problem. But not sure there could be any problem in this approach.
Want your advice.

sash

  • Full Member
  • ***
  • Posts: 116
Re: Just to confirm my approach
« Reply #1 on: November 09, 2018, 11:57:06 am »
To follow a "decoupling approach" I'd rather move Dataset assignement code from main (program) unit to each corresponding form's Constructor/OnCreate.

Code: Pascal  [Select]
  1. procedure TSomeForm.FormCreate(Sender : TObject);
  2. begin
  3.   Dataset := ADataModule.SomeDataSet; // <== Assign the dataset here.
  4. end;
Lazarus 1.8.4 Unversioned directory FPC 3.0.4 x86_64-linux-gtk2

Soner

  • Full Member
  • ***
  • Posts: 101
Re: Just to confirm my approach
« Reply #2 on: November 09, 2018, 05:56:05 pm »
I would not put datasets in datamodule and use same datesets in other forms.
I did late 90's, because I read it in Delphi because and get problems after my program was bigger and I need to change something in database.
Today I put in datamodule only shared objects like  connections (i.e. TIBConnecion, TZConnection), TImageList for all forms.
It is so easy to change database or tables.

egsuh

  • Full Member
  • ***
  • Posts: 171
Re: Just to confirm my approach
« Reply #3 on: November 12, 2018, 11:09:01 am »
Hmmmm..
I see. My approach does not seem to be a good practice.
Problem is that I'd like to use a same unit in multiple applications with different database connections.
I'll think it over.

Thank you for your comments. 

mangakissa

  • Hero Member
  • *****
  • Posts: 842
Re: Just to confirm my approach
« Reply #4 on: November 12, 2018, 03:37:23 pm »
I would not put datasets in datamodule and use same datesets in other forms.
I did late 90's, because I read it in Delphi because and get problems after my program was bigger and I need to change something in database.
Today I put in datamodule only shared objects like  connections (i.e. TIBConnecion, TZConnection), TImageList for all forms.
It is so easy to change database or tables.
Datamodule is built to separate data form the GUI. That's why datasets en connections will be placed on that form.
When your form must be updated or somehing, it's easier to connect the datamodule again.
I've never heard such thing on Delphi sites

The sugestion of sash is a right thing to do
Lazarus 1.84 (32b) / FPC 3.0.4
Windows 10

garlar27

  • Hero Member
  • *****
  • Posts: 529
Re: Just to confirm my approach
« Reply #5 on: November 12, 2018, 04:45:28 pm »
I do the same as Soner.
There's no need to have aaaaaaalllll the tables alive the whole time (even if you don't need it), but I do need to centralize the connection and other non visual objects.
Besides, putting together tables in a public space, and whose visibility (responsibility) should be private for a specific class (for instance TClient, TInvoice, etc) is a way to break the objects encapsulation.

In my case I take things maybe way to far:
Lets say I have to do a desktop app with a GUI. I manage the project as if it where 2 projects one is the business domain (without forms and dialogs of any kind, thus if I need it to be library or a daemon/service or an Apache module I just do a wrapper for that particular objective) and the other project is the GUI itself. The data flow is using JSON or XML. Basically I forbid the interface to have a direct access to the data.

Thus the code is easier to maintain and to comprehend.

mangakissa

  • Hero Member
  • *****
  • Posts: 842
Re: Just to confirm my approach
« Reply #6 on: November 12, 2018, 09:19:21 pm »
There are many ways to get your data separated from the GUI.

What you says is DBComponments are forbidden tools, because they are related to data on form.
Delphi will doing the same with livebindings.

But it's no crime to use DBComponents for diplaying. You can handle all data in a separate unit.
But that has nothing to do for not using a datamodule.

I use several datamodules (sometimes for each form) The table is only active when a datamodule is created.
Lazarus 1.84 (32b) / FPC 3.0.4
Windows 10

garlar27

  • Hero Member
  • *****
  • Posts: 529
Re: Just to confirm my approach
« Reply #7 on: Today at 02:37:32 pm »
There are many ways to get your data separated from the GUI.
Yes, that's right! I tell what works for me at the moment....

What you says is DBComponments are forbidden tools, because they are related to data on form.
No, I didn't mean that. In fact I use a lot of TDBGrids, and some TDB* but I do not connect them to the main database, I connect them to (for instance) a TMemDataSet whose data was taken from a JSON, XML, a collection or an array of records. It sounds like a a lot of work but it pays off at maintenance time.

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus