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

We are a small software house specialising in DTB APPS with database engines and have come up with plans similar to the ones above, but with slight differences. This is our interpretation of the (largely acedemic, Dont Get Bogged Down!!!) argument. I use a "Customers MAintenece" example to illustrate terms.

Presentation Layer

Responsible for displaying data and accepting user input. ie, accepts new customer details

WorkFlow Layer

This is the so-called business objects layer, containing validation rules and business processes. It also calls the standard functions in the Database Driver in the sequence and logic needed to complete a transaction. For example, here is the vb-(ish) psudo code for an "add new customer" routine.

std.GetCustomer (newcustID)
IF [Customer Exists]

   Raise Error "Customer Already Exists" Else

   std.AddCustomerRecord(Customer Details.......) Endif
If [Records Effected] = 1 then

   [Everything OK]
else

   Raise Error " Addition Failed"
Endif

Database Driver

These are set routines to perform certain "indivisable Business Transactions" such as GetCustomer, AddCustomerRecord, delete customer etc, that may or may not return disconnected ADO recordsets. Mostly they consist of routines to build SQL statements and pass them to the Database engine. It is compiled as a separate DLL for interchangability as the database engines accept different dialects of SQL. For example, there may be a driver for SQL, Access, oracle etc.

I hope this is some use, or even better, somebody comes up with a major flaw in it (it would save us a major re-write!!!), any comment or criticisms welcome)

Cheers

        _
ROB dd

--
Rob Simpson Received on Fri Jun 25 1999 - 11:04:06 CDT