The iBATIS philosophy - iBATIS in Action - page 26

intricacies, and dependencies of an enterprise database. In addition, they have bat-
tle scars from years of modifications, quick fixes, cover-ups, workarounds, bandage
solutions, and technical limitations. Furthermore, legacy databases are often
implemented on older platforms that are not only outdated but are sometimes
totally unsupported. There may not be adequate drivers or tools available for mod-
ern developers to work with.
i BATIS can still help with legacy databases. As long as there's an appropriate
database driver available for the system you're working with, i BATIS will work the
same way it does for any database. In fact, i BATIS is probably one of the best persis-
tence frameworks around for dealing with legacy data, because it makes no
assumptions about the database design and can therefore deal with even the most
nightmarish of legacy designs.

1.4 How iBATIS handles common database challenges

On modern software projects databases are often considered legacy components.
They have a history of being difficult to work with for both technical and nontech-
nical reasons. Most developers probably wish that they could simply start over and
rebuild the database entirely. If the database is to remain, some developers might
just wish that the DBA s responsible for it would take a long walk off a short pier.
Both of these cases are impractical and unlikely to ever happen. Believe it or not,
databases are usually the way they are for a reason—even if the reason isn't a good
one. It may be that the change would be too costly or there may be other depen-
dencies barring us from changing it. Regardless of why the database is challenged,
we have to learn to work effectively with all databases, even challenged ones. i BA-
TIS was developed mostly in response to databases that had very complex designs
or even poor designs. The following sections describe some common database
challenges and how i BATIS can help with them.

1.4.1 Ownership and control

The first and foremost difficulty with databases in a modern enterprise environ-
ment is not technical at all. It is simply the fact that most enterprises separate the
ownership and responsibility for the database from the application development
teams. Databases are often owned by a separate group within the enterprise alto-
gether. If you're lucky, this group may work with your project team to help deliver
the software. If you're unlucky, there will be a wall between your project team and
the database group, over which you must volley your requirements and hope that
they are received and understood. It's a sad truth, but it happens all the time.