What a coincidence! I have a KMoverObj question too!

After traversing through the KMoverObj.Save() code and watching what happens, we decided to try it out. However we now have a concern.

If we let the SelectMoverObj (sp?) do the saving... that means that we're letting it bypass the Business Object's duty. Things such as what goes on in its PreSaveHook() and any Business Rules. Plus, if some day in the future, the table/view/object changes, instead of only looking at the Business Object, we now have to find all these form-level objects that might be affected by these changes.

Kevin's done such a good job of keeping the tiers/layers separate, that I'm surprised to see this problem. So I'm wondering if I'm overlooking something.

Now I have to throw in a disclaimer quick, before someone pops up with it... I do know he has notes that IF I want to change SelectMoverObj and use my own Business Object I can. However there's a slew of code in the SelectMoverObj I wouldn't want to lose! And even if I did copy the method code he wrote down in the book, that seems like a lot of work to do for each KMover... especially for one that works good practically As-Is. But is this the only solution to not break the Business Rules?

Dustin