RE: Application design

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: M. Lazarus
>
>   Can you give a real life application scenario (maybe order entry /
> billing / inventory), specifying what functions would be taken care of in
> which layer and what criteria would you use?

I'm sure you didn't mean an entire application, Mark, so I'll try to map out
a single function.  Let's take, say, price lookup.

There are a million permutations, obviously, but let's use one of medium
complexity.  The concept here is that the tier (or layer) 2 business
function is:

  GetPrice(customer : item : quantity : date)

Note I'm using RPG ILE syntax, just for the fun of it.  The only difference
in Java would be to determine which object the method actually belonged to.
In this case, I'd probably go with item, thus:

  item.getPrice(customer, quantity, date)

Okay, this is the business logic layer.  Now down to the database entity
layer.  In order to calculate the actual price for this item, I may need to
take into account things like total sales for this customer.  To do that,
I'll need a business attribute, TotalSales.  This is definitely a customer
attribute, so I'll do it like this:

  GetTotalSales(customer : item )
  customer.getTotalSales(item)

In either case, the total sales by item for a customer is a business entity.
How that data is stored in the database is immaterial to the application.
It could be stored in two files on two different machines - the last 90 days
of history are local, while older data is stored on another machine (a bit
farfetched, but you get the idea).  The data could be gotten via SQL, native
RPG I/O, or a call to a server on another box (or any combination of the
above).  This code makes up the tier 4 deployment layer.  The job of the
tier 3 provider is to get the data from the tier 4 deployment layer and
present it to the application.  This is pretty much a straight mapping of
database fields to attributes, although it can, as I've shown, get pretty
complex.

This level of abstraction allows the application programmer to concentrate
on the business, while the database programmer can use whatever tools best
suit their purpose.  This also, by the way, allows a level of platform
independence above and beyond that of SQL, which is notorious for
inconsistencies among platforms.  With this architecture, you can add new
non-homgenous databases by simply modifying the tier 3 attribute reporter
and writing a new tier 4 data deployment module.  The business logic won't
change at all.

Joe