Re: Architecture ideas for n-tier app with diff backends

This is an excellent approach, Rebecca. I can state from experience that at least one mega-broker here in the US successfully rolled out a 5000-user application written that way (a suite, really).

Regards,
jh

In comp.databases.oracle.server Rebecca Riordan <rebeccar_at_magna.com.au> wrote:
> Peter,

> FWIW, in my experience, the three-tiered model doesn't work very well for db
> apps. You might want to have a look at the four-layer model, which divides
> the functionality into:

> - User Interface layer (responsible for presentation)
> - Data Interface layer (handles data manipulation in memory, tightly coupled
> to the UI layer)
> - Transaction interface layer (builds and initiates queries and enforces
> business rules)
> - External access layer (talks to the data engine)

> This division just seems (to me, anyway <g>) to map more naturally than the
> 3-tier thing. But the big advantage of this model for the kind of
> environment you're describing is that _only_ the external access layer
> components are engine-specific, and if you design them carefully they can be
> generic. Thus, having written a Jet 4 EAC or a SQL 7 EAC, you can use the
> same component in every application that talks to the engine.

> As I said, FWIW....

> - Rebecca.

> Peter Daniels <peterd_at_snapsystems.com> wrote in message
> news: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
> >
> > 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.
> >
> > 3) The compromise between leveraging dbms specific functionality and
> > maintaining easy revision control for conceptually similar data access.
> >
> > 4) (a continuation of 3) using straight ANSI SQL in data tier components
> > vs dbms specific stored procedure languages.
> >
> > I hope this thread will provide insight for the armys of developers
> > required to design for multiple dbms.
> >
> > -Peter
> >

--

Jared Hecker	| HWA Inc. - Oracle architecture and Administration
jared_at_hwai.com	|  ** serving NYC and New Jersey **