hcOPF - A Reusable Settings Dialog

One of the things I like best about using an OPF is that an application can usually be sectioned into re-usable pieces if you aren’t dependant on the data layer chosen, and using an OPF inherently removes a great deal of your dependancy on that data layer.

Once you choose Oracle as your database, anything that talks to the database is no longer re-usable if the database is changed to SQL Server for instance.  You can of course, limit these dependancies by crafting the code with this in mind, and limiting any database stored procedures or functions utilized.  Unfortunately, it’s been my experience that this just doesn’t happen.  Either it’s development time constraints to remain competitive, lack of foresight, or just a poor choice for the initial RDBMS.  By the time the product gets to the point where the database needs to be changed to provide better scalability, or suit a target client, it essentially requires re-development because it’s too tightly coupled to the DAL.

Using a DAL like DBX, or ADO helps in that you can connect to a variety of different databases, but it doesn’t solve the problem that different databases support different column types and SQL syntax.  For example, Interbase doesn’t support the bit datatype commonly used in SQLServer.  To handle such differences you could create separate datamodules and try to abstract them so on start up the application could determine which datamodule to use.  This requires a great deal of effort and forethought, which in practice, seldom happens.  Conditional compilation is another option, but it can get quite cumbersome.

An OPF solves the datatype issues by providing translations from the Field types the selected Delphi DAL maps to the database columns, to object attributes.  A boolean object attribute can be stored as a bit in SQLServer and a Char(1) in Interbase, and all that has to be changed in your code is a single line that defines the attribute metadata.

You still have to deal with any database specific code if you choose to override list Load/ApplyUpdates or object Read/Write methods, but the RDBMS specific code is drastically reduced.  It works so well, that I used hcOPF to enable me to work on an Oracle 10G based application at home.  I didn’t want to install or maintain Oracle on my home machine, so I used Firebird at home and Oracle at work, with almost identical source code, using a conditional directive to isolate the minor differences.

The added benefit is that you can code re-usable application pieces, such as the classic Settings or Options dialog found in most applications, including Visual Studio.  Using dynamically created mediators, the entire dialog can be data driven, and re-used across projects regardless of the database employed.  The only requirement are the basic Settings table structures.  Supporting the editing and validation of a new setting is as simple as creating a database record.  This is one step above component development, and could even be deployed in a package to maximize re-use.  Don’t expect this code to make it into hcOPF though, it’s not my IP to give away.

Leave a Reply