|
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?
|
