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

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
>
Received on Mon Jun 21 1999 - 02:32:27 CDT