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? _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/001c01ca1c3e$89245450$9b6cfc...@com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
