0

I have a DataModule and I want to have many (>50) datasets inside of it. I plan to request data from that datasets via functions and procedures.

The question is, what is the best way to organize datasets in the DataModule?

I see three options:

  1. One design-time component for each dataset.
  2. One common design-time component dataset for all datasets. Text of SQL command and other properties are set dynamically inside a corresponding function or procedure.
  3. No design-time components. Each dataset is created in the run-time inside a corresponding function, then it returns data to this function and gets destroyed.

How do you think, which way is the best? Or none of above? Are there any other ways to efficiently organize many datasets inside a DataModule?

Vasiliy Volkov
  • 745
  • 8
  • 10

3 Answers3

1

I've seen all those possibilities and while two and three are very flexible, method one at least offers highest and fastest readability and offers quickest access for debugging by a person not as involved in the code. BUT I would choose a mix of one and three where frequently used datasets will be in the datamodule and not so frequently used ones or datasets that will be changed at runtime will end up in some local method.

Sherlock70
  • 564
  • 10
  • 24
1

I have used the following setup in the data module:

1) Design-time components with design-time queries for:

  • data that will be present in your app for a longer time, e.g. data for user interaction like grids. Often with providers and clientdatasets concatenated to the query component.

  • datasets for repeated lookups (so usually with parameters)

I gave them names referencing the entities that they were retrieving/updating. Clear for debugging and for other people.

2) Design-time components without SQL for ad-hoc lookups and updates, usually just a generically named QryLookup and a QryUpdate. I just set the SQL at run-time and execute. Often without datasource etc.

Jan Doggen
  • 8,799
  • 13
  • 70
  • 144
0

They are good choices depending on your project.

Option 1. Much repeated code to maintain. Hard to find the dataset you need to edit to be defined in the. dfm. Not easy debugging.

Option 2. Less code to maintain but harder to edit with long strings of SQL!. Easy debugging.

Option 3. I think it's very similar to option 2.

David Miró
  • 2,694
  • 20
  • 20