Warthware Logo
Building blocks for better software ...

Data Access Layers

Developing applications that access data can take on several different approaches. The first approach is to implement SQL calls where ever they are needed. This has the disadvantage of adding complexity due to having to maintain SQL in multiple places. A second approach is to implement code that accesses data within copybooks, includes, header files or SSIs. However, when these modules are changed, modules that use this code need to be analyzed for impact and often recompiled (except in SSIs) which can also lead to greater maintenance costs. A final approach is to build a data access layer in which all SQL is handled by homegenous compiled modules or classes. While this adds time to development costs, it has the advantages of standardizing the access to data, minimizing maintenance and maintenance costs and isolating SQL to a particular layer.

Developers always want to reuse their code whenever possible. Making that code reusable is often a challenge and requires maintenance of the reusable portions of code in order to make it work. TACG helps this process by generating data access code in classes which have a standard interface from table to table. For developers to code data access modules from scratch or to duplicate others can take days, but using TACG as soon as the table is defined the click of two buttons can generate a class in a few seconds. More importantly, the code is error free. TACG removes the mistake factor from the equation and doing so can reduce testing time significantly.

There are some who might argue that data access layers are overkill, and depending on the scale of the system, they could be correct. However, what if the data access layer modules could be mechanically generated? Wouldn't this make a data access layer more feasible? Additionally, there is a trade off between development costs and maintenance costs. If your software has a life expectancy of ten years, then you will want to spend enough time during development to make the software more maintainable. Data access layers can decrease maintenance costs significantly. While the data itself might change, the interface that accesses the data does not necessarily have to and that is the most significant characteristic that contributes to reduced maintenance.

Finally, limiting SQL to a single module isolates SQL to a certain set of modules. Being such, having a staff full of skilled SQL developers is not necessary because that code is limited to only those modules that access the data. In a lot of cases, customization to standard data access code is not even necessary and because data access is limited to the data access layer it is easier to enforce standards in SQL and programming.

Tools like TACG can save time and money in development and mainteance costs. TACG creates a standard interface that developers can become familiar with. This reduces the time to develop overall by allowing developers to spend more time on other function besides data access and cuts down the time required to develop a data access layer from days or weeks to seconds. Because TACG creates a data acceess layer, there are reduced maintenance costs inherent to that approach. Finally, the number of high cost database experts required is reduced because SQL is isloated to the data acces layer requiring fewer people that need knowledge of SQL. Realistically, using a tool like TACG could reduce development and maintenance costs by many thousands of dollars. That is not bad when you consider the cost of TACG itself.

Why not try TACG?


Copyright © 2002 - 2019, Donald R. Warth Jr.
All rights reserved.