We have a dilemma. In our first project, we made BizObj's for everything under the sun. Just about every important table had an object representing it. This time around, we were thinking we'd keep the BizObjects down to the minimum, and see if we could make each BizObj do more.

However, now I think I know why we did it the other way.

Here is the first of many dilemma's:
We have a DeductionObj, and a TaxObj. (Pretty simple so far...)
We have a table and view that represents "DeductionTax". (Each deduction may be affected by many of the Taxes. In the old days, this representation is nothing more than a linker table (depending on your terminology).

However, we're writing some code that will ADD and DELETE new records in the DeductionTax table/view. We can either make a new BizObj called DeductionTaxObj and call its "New" method. OR... we can make a method in the DeductionObj called "MakeNewDeductionTax" and put the code in there. However, now we have to mimic Kevin's NEW() or SAVE() code to cover all instances.

We also don't know if calling DeductionObj's DELETE() method is wise, because although it does use the correct view (due to CurrentSelectedAlias) would I ever some day add BusinessRule code in the DELETE() method that was suppose to affect Deduction table, not DeductionTax table?

Sorry if this is unclear, but to sum up quickly:
When I think of DeductionObj..... I usually think of the rules affecting Deduction records found in Deduction.dbf and views. Not necessarily DeductionTax.dbf and views.

I've asked this once a long long long time ago, and I think I was told either way was fine? ugg...