>>
>>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.


I sure wish in the end I understood which way you were leaning on this topic. Are you suggesting he should not instantiate another business object from the Policy Business object? One option would be to have another object say a PolicyManager object that would instantiate both to coordinate the work and return the results, but it sounded to me like the actual work being returned belong to the Policy business object. I see no reason why it shouldn't just go get any additional info it might need to accommodate that work effort. It shouldn't probably return information other than Policy information however.
Your thoughts?
Tim