 |
AppletTalk.com Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
JS Guest
|
Posted: Tue Jun 14, 2005 1:25 pm Post subject: 3-Tier architecure? |
|
|
As I understand a 3-Tier architecure contains:
1) Presentation layer (JSP sites)
2) Process management layer (where logic on userinput is made)
3) Database management layer
But what is the third layer? Does it only consist of the Database or does it
also include the interface that is made to make operations on the database?
As I understand it it is necessary to make an interface that works as a
connection between the process management layer and the database management
layer. If it is needed to change the database its only necessary to change
the interface. Based on this it does not make sense that the interface is
part of the third layer.
Where can I find more info on this? Have tried to search google but I only
found rather cursory information.
|
|
| Back to top |
|
 |
Tom Dyess Guest
|
Posted: Wed Jun 22, 2005 1:25 pm Post subject: Re: 3-Tier architecure? |
|
|
"JS" <dsa. (AT) asdf (DOT) com> wrote
| Quote: | As I understand a 3-Tier architecure contains:
1) Presentation layer (JSP sites)
2) Process management layer (where logic on userinput is made)
3) Database management layer
But what is the third layer? Does it only consist of the Database or does
it
also include the interface that is made to make operations on the
database?
As I understand it it is necessary to make an interface that works as a
connection between the process management layer and the database
management
layer. If it is needed to change the database its only necessary to change
the interface. Based on this it does not make sense that the interface is
part of the third layer.
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.
--
Tom Dyess
OraclePower.com
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|