Not a problem, Carl, this is always the most "interesting" part of the coding... the design.

To hopefully further clarify, HostObject only refers to the object that *created* YourBusinessRule object, not necessarily the one that *called* it. Subtle, yet important distinction. You probably already understood that, but I just wanted to be clear.

What you could do here is create an InvoiceHeader object and give it a property of type InvoiceItem. Now, you can freely interact directly with InvoiceHeader and have it delegate whatever responsibility belongs to InvoiceItem using that property.

We found this works well with our Customer/Address object relationship. We felt it was more intuitive to call Customer.ChangeBillingAddress() instead of Address.ChangeAddress() -- especially since Address records are in the context of some other entity... orders, shipping, etc. Maybe this describes your Invoices/InvoiceItems relationship as well?

As far as rules, we've added only those rules that govern saving, inserting, and deleting records. So far, none require services from another business object. Where we've needed lookup data from another table (e.g., before adding a new order, we total the writeoffs for the customer) via stored procedures.

If that doesn't clear up the picture, maybe giving us more information on what types of functions you're performing in your rules objects now would help us better answer your question.

---J

>Thanks, Jason. I guess (no, I know) I'm a bit dense here...
>
>If I use YourBusinessRule.HostObject, then I'm refering back to the biz object that called the biz rule in the first place - is that correct? If so, then that would not work as I need to reference a different business object.
>
>On the other hand, if I create business objects from within the business rule object, then I have some redundancy going on... I have a business object created in the usual way, and then I have to create another one embedded in the business rule that does the same thing. In that case, I've just lost all the advantages of an n-tier, OOP design. Of course, the most likely scenario is I just simply don't properly understand the answer :)
>
>What I need is something like an invoice object which as a whole represents the invoice header AND invoice items, for example. The way I have to relate the parent and child objects now, well, I'm doing it in the web page form code. Seems like I should be able to define one invoice object that encapsulates the whole "invoice".
>
>Regards,
>Carl.