>>>>>Just working through some ideas here, hoping that writing it out will clear it up in my head, or if not, then someone else may give me some feedback.
>>>>>
>>>>>I'm working on some software for an Insurance Company. We have Insurance Policies based on Plans and Plans have Premium Rates which vary according to smoker, age & sex of the Policy Holder and the sum assured of the Policy. For an individual Policy I need to calculate the premium due. So I'll create a CalcPremium() function on the Policy BO. Within this function I need to get the Premium Rate to use. Should I have a GetPremiumRate() function on the Policy BO which pulls the data from the Premium Rate table, or should that be on the PremiumRate BO?
>>>>
>>>>
>>>>Both. in your Policy BO you can instantiate the PremiumRate BO, call a method to return the premium Rate, and then finish your calculation. You should let the PremiumRate business object retrieve the data but there is no reason you can't instantiate that business object from within the first business object.
>>>>Tim
>>>
>>>Thanks Tim,
>>>
>>>I think that's what was bugging me: instantiating one BO within another.
>>
>>Perfectly OK in my opinion. I guess it should be since I do it. :-)
>
>I think what is/was bugging me is that in my VFP framework I would have done this at a level higher than the BO. I use a BOManager that coordinates all the separate BOs and calls the various bits in order to do the calculation.

Like a watch, your application is already a container for the parts. In a watch, one cog does not instantiate another cog. In the virtual world of software, that is possible, but slow. In a real watch, both cogs already exist and are linked at all times while the watch exists physically - runtime. Instantiate both and have them communicate. Your CalcPremium method in the PolicyBO just calls the CalcPremium method of the PremiumRateBO and does anything further it needs to do. It is the contract between the two objects.