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

Rebecca (and Peter),

What you write is exactly in line with the experience we have at our site with application development for the next generation. We started out talking about a three-tier model and, after a lot of ado, ended defining a four-tier model. There might be a slight difference in emphasis between what we have done, and what you describe, but only slight...

As I see it, we have effectively split the middle tier in two. This enables one to place the code in these layers in the optimal position: code that is strongly

related to data presentation is placed in the Data Interface Layer (we call this Workflow Layer), code that requires data access can be written to be part of the Transaction Interface Layer (we call this the Business Layer). It seems almost superfluous to say that the Data Interface Layer runs on clients, and the Transaction Interface Layer runs on application servers, in our ideal representation. That way, data traffic over the (possibly low-bandwith) network is kept to a minimum (we suppose the network between application servers and database servers will generally be a high-bandwith one).

Having split the software running on the client in two parts in theory allows for an easy implementation when browser support is an issue. Al you need to do is write some applets that talk to the Data Interface Layer, that can than be placed on your web server (sounds easy, when you just write it down).

Since we are to develop this software using MS technology, we are currently using MTS for the Transaction Interface Layer. Though I don't work with this directly, I gather this is not easy to work with, to put it mildly. We are currently considering writing the services ourselves, in order to overcome the shortcomings of MTS (we already did for some services). Database access using ADO is relatively simple, a lot simpler than using JDBC (we are uisng Java, or better J++), I think. We mainly had to write some wrappers for ADO objects, making them more accessable. I must in fact say that ADO is not very accessable, at least about a year ago the documentation was poor and completely focused on Visual Basic. The wrappers provided in the WFC classes are very useful, however.

Writing a generic Data Access Layer is a very good idea. If you do not rely on the RDBMS to perform certain tasks (like referential integrity), you could even persist your data in flat files, using this generic layer.

Finally, a word of warning against relying on ANSI-syntax. Unfortunately this is an issue that is poorly supported by lots of RDBMSs. One disturbing example is the fact that Oracle does not support ANSI outer join syntax (no pun intended against Oracle). This makes it a very good idea to work with a single abstract class that implements your standard SQL-generation, and product-specific concrete classes that inherit from the abstract class and override methods where necessary.

Regards,

Ruud de Koter

Rebecca Riordan 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
> >
Received on Tue Jun 22 1999 - 02:09:24 CDT