From: www.itworld.com
July 15, 2002 —
The problem -- or at least the engineering challenge -- with business
logic is that it's frequently not tidy. A single piece of business
information may derive from a calculation involving many subsidiary
values.
Corporate earnings, to cite an example of apparently little importance
to American public companies these days, can be derived from (among
other things) gross revenue, gross expenses, taxes paid, depreciation of
assets, and amortization of capital expenditures. Those component values
likely exist in your computing environment as distinct objects, which in
turn come from different database tables. If your job is to deliver an
earnings number to a software client, then you have a complicated task
at hand.
You can realize a bit of an efficiency increase by doing your "object
gathering" on the business logic tier, rather than expecting your client
to make a bunch of queries. You run a couple of risks, namely:
* The information in the aggregate object at the business tier
becomes obsolete, or,
* You make just as many queries to the back end from the business
logic layer as you would from the presentation layer.
Even if the latter drawback is the case in your system, you'll still
probably better off than you would be by doing the queries from the
client; the bandwidth between the business logic layer and the back end
is (probably) very high, and the latency there is likely low.
This sort of design is used for all kinds of problems, and is,
therefore, called a software pattern. Specifically, it's called a value
object aggregator, or value object assembler.
Before we build our value object aggregator class, we need to establish
some value objects to aggregate. A typical value object looks (in part)
like this:
public class ExpenseVO {
public Date expenseDate;
public Double expenseTotal;
public ExpenseVO (Date expenseDate, Double expenseTotal) {
this.expenseDate = expenseDate;
this.expenseTotal= expenseTotal;
}
}
How do we stitch value objects like this one into a more useful whole?
That's the subject of next week's installment.
ITworld