RE: Java code help...

This is why you have tiers.  In the classic distributed architecture, you
will have an application tier, a logical object tier, and a data tier.  The
application knows only about the object tier.  The object tier in turn knows
how to load itself from the data tier.  The data tier represents the data as
physically stored on disk, while the object tier represents logical business
objects.

Business objects aggregate attributes from one or more different data
objects.  However, there are two common erroneous assumptions: that the
attributes are fixed, and that the attributes are static.

In fact, a business object may perform data access to load its attributes,
and these accesses may come from different data objects depending on the
circumstances.  In the case of the former, an order may be instantiated
without yet loading its history.  The history may not be loaded until it is
actually accessed by the Order object's getHistory() method.  As an example
of the latter, a runtime switch may tell an order that its appropriate A/R
account is from either the customer or the corporate customer.

The trick is to successfully encapsulate the business object DISTINCT from
its physical data layout.  While in many cases the business object will
simply be a relatively close approximation of the data on the disk, in other
cases, it will be very different.  Thus, you can have an Order class, a
PricedOrder class, and a HistoricalOrder class, all with different
attributes, but all of which talk eventually to data tier objects to get
their information.

Now it is no longer an application decision as to whether or not the data
tier objects should get all the fields from the database records or only
those that are requested by the business object.  It is instead an issue for
the business object designer.  This "logical middleware", if you will,
serves to shield the application programmer from the complexities (and
details!) of the database.

And if in fact a new business attribute is required, the application
programmer and the business object programmer decide on how the attribute is
to be exposed.  They agree on the signature of a new method added to the
business object interface.  Note that this method may or may not require
database changes - it may simply require accessing a different data tier
object.  If (and ONLY if) the attribute requires physical data changes, the
business object programmer then discusses the changes with the database
designer, and they work out a similar sort of contract.

Why is this important?  Because, if the database layout changes, the only
person affected is the business object programmer.  And if the business
object is not affected by the change (for example, if the database
programmer simply needs to add a new field for some OTHER business logic
change), then not only doesn't the business object change, but neither does
the application logic.

Climbing back up one level, this means that your original assumption of
having a container of records from your result set is simply the wrong
approach.  Instead, you have a business object which may or may not have a
collection of other business objects.  Those objects populate themselves
through the data tier, which in turn decides which tables and columns (and
which machine, which network, which data medium) are used to load the data
object's attributes.

The major benefit of this approach is that your applications can run with
absolutely no clue as to how or even where their data is stored.  The
primary drawback is that you need a business object programmer.  But if your
application is sophisticated enough to require even three programmers, then
its sophisticated enough to split those three up into tiers.  Productivity
goes up quickly, believe it or not, as your programmers get the hang of the
requirements of their own specific tier, and realize that they don't have to
worry so much about the vagaries of the other levels.

Of course, you will STILL need someone to oversee the whole thing,
preferably somebody who has had some experience (successfully!) designing
database applications.  This person will make sure that the layers work with
one another, and that you don't find yourself writing an application that
repeatedly accesses a business object that in turn selects a single database
object from a million record file with no matching access path.  Even a
proper tiered architecture doesn't remove the need for a good, knoweldgeable
development manager.

Hope this helps.  Probably not.  It's clear to me, but often hard to
explain.  If you'd taken my class on building a tiered application at
COMMON, you'd have seen a working example of this approach.

Joe Pluta
www.plutabrothers.com

> -----Original Message-----
> From: Brad Stone
>
> Ok.  Let's say you have a list container that holds records
> from your result set.  Say a vector of the base object.
>
> Now, in this thread I've read that you shouldn't select
> fields you don't need.  I've also heard that to minimize
> work with table updates, to follow the example as Fred has
> shown.  (BTW, great example).
>
> Now, if I am hiding the data from my user, the container
> they use will need to contain all the fields, since they
> really won't know which fields (or members) they will need.
>
> So, this eliminates the "don't request a field unless you're
> going to use it" idea, at least in my view.  Because the end
> user doesn't deal with a result set or affect the fields
> selected and used in the container when it is loaded.  They
> simply .load() the class.
>
> I can think of ways that the user could be allowed to choose
> the fields to load, but then how would the class loader deal
> with that?
>
> thinking out load again...