Might I suggest a slight variation? An invoice demonstrates a need to
deal with sets of records - the line items. There may even be several
parent records each with their own children that have to be committed.
Agreed. Business objects modeling anything other than the simplest
objects will often have 1-to-many objects. Take a hypothetical
"Inventory Receipt" BO: it needs to update inventory on-order, on-hand
for a number of items, order headers and details, accounts payable
records, vendor records and more.
For my framework, I went with the idea that the BO should be more than a
transfer mechanism between GUI and back end. It should "model" something in
the real world. My base BO class can handle one parent table and zero or
more one-to-many or many-to-many "children" of that parent. So when
modeling a "person", for instance, the object can have at hand that
person's name, his/her contact information, his/her demographic data,
his/her service record, etc. In another situation, the same BO base class
can be subclassed to model a "job", with a controlling job number, the job
schedule, person responsible to oversee the job, any number of people
contracted to perform the job, and so forth. Calling for a particular
parent record instantly brings forth all the relevant child data, ready for
use by the GUI. Optionally there are hook methods for bringing in lookup
data that isn't directly linked to the parent record, as well as metadata
that the GUI can use to provide the appropriate interface for the model
(though I realize that fudges the model, it's just more convenient). Also,
the same table may be "parent" in one BO subclass and "child" in another
one, so it's the BO that defines and maintains the relations between tables.
The downside is that not much of the setup work is automated. I have to
enter quite a bit of configuration information to make the BO work. I was
in a hurry to start coding the application the framework was built for and
didn't want to spend a few more weeks working on a BO builder. I'll
probably add one eventually--though even then it won't be extremely
prescriptive; it's important to balance RAD-ness with flexibility.
Ken Dibble
www.stic-cil.org
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
