Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Architecture ideas for n-tier app with diff backends
The most seroius problem with n-tier architecture that some
existing end-user tools (MS Access for example, or Oracle
data mining tool) are developed to be connected to the certain
tier in your design (to say, to directly use the actual data via
ODBC). So, the design of the whole system becomes more
complicated. The most common solution is to allow read-only
access for the underlying levels.
Peter Daniels <peterd_at_snapsystems.com> wrote in article
<3766A024.B4962E4E_at_snapsystems.com>...
> We are in the proccess of converting our MS Access 97 based application
> to a 3+ tiered app that will be able to use either an Access 97, Access
> 2000, SQLServer7, or Oracle 8.0.5 backend. I would like to open a
> discussion about the caveats, tricks, and tips involved in such an
> architecture. Currently, we are only concerned with the data tier. I
> have a few ideas to fuel the fire:
>
> 1) separating the tiers into presentaion, business rules, data access,
> dbms
I'll assume presentation - business rules - object model - data access -
dbms.
At object model level you can do some generalisation of data and
provide the better multi-user capabilities.
> 2) breaking the data access tier into a single interface for the
> presentation layer and possible multiple child interfaces for actually
> talking to the different dbms.
Those child interfaces usually turn into specific SQL statements for different dbms'es. In this case your data access level should provide necessary transaction control. Anyway, it can do it better than dbms.
> 3) The compromise between leveraging dbms specific functionality and
> maintaining easy revision control for conceptually similar data access.
For just SQL scripts it is easy. The automated testing is also possible (load the same data - get the same responce), but you will need very detailed description of the stored procedures for developers.
> 4) (a continuation of 3) using straight ANSI SQL in data tier components
> vs dbms specific stored procedure languages.
There ain't such thing as an ANSI SQL.
> I hope this thread will provide insight for the armys of developers
> required to design for multiple dbms.
>
Alexander
Received on Wed Jun 16 1999 - 03:56:45 CDT