|
One farmer's adage states "Don't try to put
10 pounds of potatoes in a five pound sack." Although this
would seem to be common sense, I was in the middle of a Delphi
project that attempted to get to the 10 pound limit and beyond.
The visual programmers of the team needed access to over 70
database tables on a multitude of different forms. One master
datamodule became the traffic cop for all 70 tables as well as
business logic that manipulated the data. Since any one form
would use 2-20 tables, there were many instances of queries and
datasources (at least 5 pounds worth) that were not being used in
the datamodule. However, if we tried to break this big datamodule
into smaller datamodules, we found that some forms required very
diverse combinations of tables. Maintenance of the multiple
datamodules would become a problem, while some of the forms
continued to require multiple datamodules. With a good deal of
experimentation, I have tried a variety of techniques to strike a
balance between a central datamodule that is easy to maintain but
trim at runtime. The following methods describe the evolution of
housing queries and datasources within Delphi projects. |
||||||||||||||||||
 Method 1: TQuery/TDataSource on
all FormsThis is the good-old method that has been with us since Delphi 1. What could be easier than placing a query on the form and linking field to a local datasource? Although this is RAD 101, it causes problems in maintaining the database. Since the many forms in a large project, a query many be needed in any places. Any changes to a table may need to be made on many forms. In addition, the business logic that accompanies the query is duplicated as well. In Delphi 2, a major advance was... |
||||||||||||||||||
 Method 2: Components in DatamoduleThe datamodule is a convenient place to keep all queries and datasources. In addition, any of the business code that manipulates the database could be centralized as well. The problem with using a single instance of a datamodule is managing multiple forms. As focus shifts between forms that share the links of a database, the datamodule needs to focus on the correct records to support those forms. Although the single instance copy of the datamodule saves memory and resources, a programmer must build routines to keep the right data one the right form. |
||||||||||||||||||
 Method 3: Many
Instances of DatamoduleIn order to keep the synchronization between a form and datamodule, each form could have its own instance of the complete datamodule. This may be the least efficient way to use runtime resources. Like Method 1, the table business logic is duplicated within each instance. In addition, there will be datasources and queries that are unused on the datamodule. Like Method 2, database maintenance is simplified because the logic is centralized. |
||||||||||||||||||
 Method 4: The Dynamic
DatamoduleThe dynamic datamodule's goals: • Allow each form instance to have a matching datamodule • Tailor a datamodule to match the dataset needs of the form. • Break all business logic out of both the form and datamodule. |
||||||||||||||||||
| Show me the code! As those Linux folks know, a great way to learn and build new features in your systems is to use the open source. To see the dynamic datamodule technique described in Method 4, help yourself to the example code available through the link below. This code is offered without copyright and you may wish to use it as a framework for your own tests. I would really like any feedback that you can give: please contact Chuck Weindorf at Charles.Weindorf@mudsox.com |
||||||||||||||||||
 How a Dynamic Datamodule works: The datamodule is very thin - the queries and
datasources are declared as public variables. When a form is
created, an instance of dtmDynamicDatamod is also created. The
main menu calls pmDatamoduleManager with the instance of the new
form. pmDatamoduleManager scans through the form visual component
list and checks the tag field for datalinked fields like tdbedit, tdbgrid, etc. Each tag matches a specific query and datasource
combination. |
||||||||||||||||||
|
||||||||||||||||||
|
prmDatamoduleManager creates the query and datasource and links the field to the correct component. The result is a datamodule that will automatically adjust as the programmer adds visual components. For example, to pull a field from a new table, the programmer would add a tdbedit component with the field name and the correct tag number. At runtime pmDataModule manager detects the new tag number and creates an instance of the correct query/datasource. |
||||||||||||||||||
|
||||||||||||||||||
|
I have it. What do I do
with it?
|