> As I understand a 3-Tier architecure contains:
>
[quoted text clipped - 16 lines]
> Where can I find more info on this? Have tried to search google but I only
> found rather cursory information.
Well, you'll probably get a different answer for each language. Some say 3
tier is physicial - i.e. 1 box for presentation, 1 box for application
server, 1 box for database. Others (including me) think of it as more
logical that can be separated into separate physical boxes, but the 3 boxes
are not required. Unfortunately the term N-tier has been mangled over the
years, I can only tell you what it means to me.
If you are looking at a pure physical model with the database as a separate
box and the application server making calls to the database, it's best to
layer the database calls into separate object(s) that reside in and are
called by your business layer. For example, create a DatabaseManager object
that does all the SQL calls and only takes non-database (no
PreparedStatement, RecordSets) objects as arguements and returns only
non-database objects as return values. Often the database layer could take
an ArrayList reference as an arguement then populate it while returning
void. This is useful for a few reasons: 1. All your database calls are in a
single place and not strewn all over your business code. 2. Once you have
finished your DatabaseManager for Oracle, you can interface it and create a
SQLServer version without affecting your other code. I typically put the
DatabaseManager code in the business layer, so it would be browser/fat
client as the presentation/GUI layer, Servlet/EJB/JSP container/DCOM server
as the business layer and Oracle/SQLServer as the database layer.
To add to this, if you have multiple developers working on the same project,
it's best to break the DatabaseManager into more logical objects depending
on what your system does. For example, if you are writing medical software,
you could have a PhysicianDatabaseManager, PatientDatabaseManager, etc. This
way, developers won't be fighting over the same class in your source control
and can work in a more independent fashion.
I'm sure I'll get plenty of feedback on this, but it was meant to give you
an understanding on how/why you would want to abstract your database calls.

Signature
Tom Dyess
OraclePower.com