| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| 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
First, I want to thank all of you for getting involved. I like the 4 tier idea and
would like to discuss it further so I'm clear on the responsibilities of each tier.
Thanks again for participating, everyone.
-Peter
Ruud de Koter wrote:
> 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
> > >
--
"Funkify your life" - The Funky Meters
 |
 |