- 10, Jul 2020
- #1
Re-Introduction to FireDAC Data Access (4)
Embarcadero Team Japan - 07/Jul/2020
Combine data access function in data module
In this blog, we will explain the basic usage of FireDAC for those who have used Delphi / C++Builder to some extent.
The fourth theme
The last time
, before last
, but we have carried out exercises to create an application that uses the FireDAC, also the one of the exercises, had been placed FireDAC components, such as direct TFDConnection and TFDQuery on the form.
As is often seen in sample programs, in an actual application, data access should be centrally managed. From that perspective, the previous exercise was not practical, but rather a bad example.
So, in this article, I will show you how to manage resources for accessing the database more efficiently. Perhaps in a real application, the method described here would be the recommended implementation.
Resource octopus wiring?
Why is it bad to put a FireDAC component on a form?
I'm sure that some of you who have read the blog have similar experience with other DB components, not just FireDAC. The FireDAC component is used here as an example, but this is a general caveat that applies to other DB components as well.
TFDConnection is equivalent to the resource for accessing the database, and if the Active property is True or the Open method is executed, a session will be established with the target database.
At the same time, it consumes one database connection.
This session will not be closed unless Active property=False or the Close method is executed, so it remains as it is (unless the database is forcibly disconnected).
What would happen if we had one TFDConnection for each form?
For example, suppose you create 20 form screens, all of which need to get data from a database and display the data on the screen.
In this case, when the screen is displayed, the TFDConnection connection is opened and a session is established, so if you change to another screen without closing the TFDConnection connection, the maximum number of database connections will increase to 20. With such a screen design style, the database resources that are consumed will be unnecessarily increased in proportion to the number of forms.
The same can be said for components other than TFDConnection.
For example, a dataset such as TFDQuery consumes memory according to the number of acquired data when opened. If unnecessary datasets are not closed properly, resources on the database server and client PC will be wasted.
Placing FireDAC components on each screen in this way consumes unnecessary resources and clutters individual management. In other words, placing FireDAC components on each form is like "octopus-wiring" resources.
There is a risk of wasted use of resources by routing resources, and in some cases, the maximum number of connections preset in the database may be exceeded.
In the next section, we will discuss solutions for managing resources efficiently.
What is a data module
So how can you manage your resources more efficiently?
To do this, instead of putting the FireDAC component directly on the form, use the "data module" instead. A data module is a special screen-invisible (hidden) form that allows you to place FireDAC components from the designer's screen in the IDE, just like a regular form.
The main purpose of the data module is to separate the GUI (screen) and business rules. To take this bad application as an example, I aggregate FireDAC components that were scattered on each screen into one data module, and share this data module between each form.
By using the data module
You can manage resources efficiently.
By using the data module, the resources that used to be octopus wiring can be refreshed.
Now, let's practice the application creation that actually uses the data module.
Exercise of application creation using data module
In this section, you will practice building applications using data modules. However, instead of creating a project from the beginning, rewrite the previously created FireDAC application and change to a project that uses the data module.
The practice procedure is as follows.
(1) Open an existing project
Select [File]-[Open Project] from the Delphi / C++Builder menu to open the project saved in step (12) of the previous
exercise.
(2) Addition of data module
For Delphi, select "Data Module" from [File]-[New]-[Other]-
Combine data access function in data module
In this blog, we will explain the basic usage of FireDAC for those who have used Delphi / C++Builder to some extent.
The fourth theme
- Resource octopus wiring?
- What is a data module
- Exercise of application creation using data module
The last time
, before last
, but we have carried out exercises to create an application that uses the FireDAC, also the one of the exercises, had been placed FireDAC components, such as direct TFDConnection and TFDQuery on the form.
As is often seen in sample programs, in an actual application, data access should be centrally managed. From that perspective, the previous exercise was not practical, but rather a bad example.
So, in this article, I will show you how to manage resources for accessing the database more efficiently. Perhaps in a real application, the method described here would be the recommended implementation.
Resource octopus wiring?
Why is it bad to put a FireDAC component on a form?
I'm sure that some of you who have read the blog have similar experience with other DB components, not just FireDAC. The FireDAC component is used here as an example, but this is a general caveat that applies to other DB components as well.
TFDConnection is equivalent to the resource for accessing the database, and if the Active property is True or the Open method is executed, a session will be established with the target database.
At the same time, it consumes one database connection.
This session will not be closed unless Active property=False or the Close method is executed, so it remains as it is (unless the database is forcibly disconnected).
What would happen if we had one TFDConnection for each form?
For example, suppose you create 20 form screens, all of which need to get data from a database and display the data on the screen.
In this case, when the screen is displayed, the TFDConnection connection is opened and a session is established, so if you change to another screen without closing the TFDConnection connection, the maximum number of database connections will increase to 20. With such a screen design style, the database resources that are consumed will be unnecessarily increased in proportion to the number of forms.
The same can be said for components other than TFDConnection.
For example, a dataset such as TFDQuery consumes memory according to the number of acquired data when opened. If unnecessary datasets are not closed properly, resources on the database server and client PC will be wasted.
Placing FireDAC components on each screen in this way consumes unnecessary resources and clutters individual management. In other words, placing FireDAC components on each form is like "octopus-wiring" resources.
There is a risk of wasted use of resources by routing resources, and in some cases, the maximum number of connections preset in the database may be exceeded.
In the next section, we will discuss solutions for managing resources efficiently.
What is a data module
So how can you manage your resources more efficiently?
To do this, instead of putting the FireDAC component directly on the form, use the "data module" instead. A data module is a special screen-invisible (hidden) form that allows you to place FireDAC components from the designer's screen in the IDE, just like a regular form.
The main purpose of the data module is to separate the GUI (screen) and business rules. To take this bad application as an example, I aggregate FireDAC components that were scattered on each screen into one data module, and share this data module between each form.
By using the data module
- Centrally manage TFD Connection (number of database connections)
- Consolidate duplicate datasets to save wasted memory
- Centrally manage property settings for each FireDAC component
You can manage resources efficiently.
By using the data module, the resources that used to be octopus wiring can be refreshed.
Now, let's practice the application creation that actually uses the data module.
Exercise of application creation using data module
In this section, you will practice building applications using data modules. However, instead of creating a project from the beginning, rewrite the previously created FireDAC application and change to a project that uses the data module.
The practice procedure is as follows.
- Open the previously
created FireDAC application project
- Add data module to project
- Moved FireDAC component from form to data module
- Rewrite existing program code
- Run the application
(1) Open an existing project
Select [File]-[Open Project] from the Delphi / C++Builder menu to open the project saved in step (12) of the previous
exercise.
(2) Addition of data module
For Delphi, select "Data Module" from [File]-[New]-[Other]-
Delphi
-[Database].
For C++Builder, select "Data Module" from [C++Builder Project]-[Database] in [File]-[New]-[Other] of the menu.
[IMG]https://community.idera.com/resized-image/__size/640x480/__key/communityserver-blogs-components-weblogfiles/00-00-00-03-37/4035.image5.png
(The image above shows the dialog box for creating a new Delphi data module)
When you select the "Data Module" menu, a blank data module form will be added as shown below (the unit name will be Unit2).
The figure below is for Delphi
[IMG]https://community.idera.com/resized-image/__size/320x240/__key/communityserver-blogs-components-weblogfiles/00-00-00-03-37/5023.image1.png
The figure below is for C++Builder
[IMG]https://community.idera.com/resized-image/__size/320x240/__key/communityserver-blogs-components-weblogfiles/00-00-00-03-37/1460.image6.png
[/SHOWTOGROUPS]