>I have created some Business Object classes, and now I am creating methods on them that can be called.
>
>For instance, I have a Job business object, that will have a method called .GetItems(tcAlias) which will fetch the child records and place them in the passed in alias/cursor name.
>
>Now, I already have an old procedure that I've had for years in a procedure file that accepts a JobNo and an Alias and it does the same thing that I am wanting the Job object to do.
>
>So, I am wondering if it is a bad practice to let the call to Job.GetItems(tcAlias) just make a call to the existing procedure to get the work done? That way I have the best of both worlds where I can call the procedure in some places where I do not go the BO route, but I can also call the BO method when I am going that way.
>
>So, Job.GetItems(tcAlias) would just make call like GetJobItems(this.JobKey, tcAlias), and that's all he would do. Otherwise, I would copy-paste the code from the procedure into the BO method, and then I would have the code in 2 places! Or I could refactor my app to remove the procedure and force myself to use BO's everywhere, but that is a good chore.
>
>So it boils down to deciding if it's OK for the BO to rely on a procedure file to get his work done, or if he should be fully independent and have all his on code in his methods?

As an exercise, fire up the code references, and see where exactly are you calling the procedure. If it's in more places that you imagined, or a surprise in any way, try to see whether these places would otherwise benefit from having an instance of the BO at hand.

Besides, if the BO is lightweight (i.e. instantiating it many times is cheap), you can replace any "getjobitems(" with "oBo=create('myBizObj')+chr(13)+chr(9)+"oBo.GetJobItems(" and then you could just forget the function and use the BO everywhere.