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

The copying of the code, as described in the manual, to add my own business object is the only way I have used the MoverObj. I always change the SelListObj with one of the application's Business Objects to enforce the Business Rules like you mentioned. This way I know that any change to the object's rules are enforced throughout the business layer.

This takes more time up front in my development but time spent in maintenance is kept to a minimum which saves me the most amount of time in the long run.

Hope this helps.