We use a DataObject. Business Object, Mapper methodology.
Basically, our BO contains all of the necessary business logic for the object. If we're talking about an Employee, this is where things like Name, ID, etc. are stored. We use properties to handle all access, and maintain an _isDirty flag for changes. Depending on the level of sophistication the customer requires, we can easily modify this to store data state, so that we can maintain a full record of changes for cleanup.
We also have a DO. This handles Update, Select, Load, Delete, Insert logic for the specific backing source. We do 100 percent of this through SPs and parameters.
Finally, we have a Mapper (MP). The MP is basically a link between the BO and DO. The MP contains logic to load in a BO, and then uses the DO to save to the source. By using the MP layer, changes to the BO are comprehended, and updates are made automatically (we don't have to set the DO parameter...the MP does that for us).
Currently, we will make updates to the backing source using either the DO, or the MP. The DO is rather self-explanatory--pass in the params, and go at it.
The MP takes just a little extra effort up front (loading info into the BO, which you should probably do anyway, and then instantiating the MP), but there are several benefits. First, you don't have to keep track of what changes you need to make. The MP uses the DataAdapter, and handles them appropriately. Great if you're using a DataSet.
Also, and this is the real benefit--you limit the application's knowledge of the backing source. Some of you may be saying, "so?" I'm guessing you probably stopped reading long ago, though (or wanted to).
So, if your backing source changes from SQL to Oracle, or maybe from XML to SQL...your app doesn't care, because it doesn't know anything about that. By using a mapper level, you don't have to modify your app, only your Data Access, which you were already going to have to do, anyway!
Also, if our BOs change (and let's face it, have you ever been on a project that was perfectly defined?), the MP can seemlessly handle that, as well.
I hope this helped your question. I will add one thing--the guy that put this together for us--well--was PM on ADO.Net, so he kinda knew how to do it. (He wrote a program that actually queries the DB and writes all the SPs, DO, BO, and MP stuff for us in about 1 minute) But, the models he followed have existed in CS for a long time. It could be a little tricky to implement, but the rewards are huge.
Good luck. I'll try to review this thread in case you have any questions.

My business object might have a method called "Save" that calls the appropriate Data object's "Insert" or "Update" with the corresponding variables. The Data object then translates each variable into a parameter & calls the appropriate stored proc. You're saying you use an MP to do the translation prior to calling the DO?

The MP is what calls the DO, and it does it on its own. We'll call the MP's Update, and it does the rest.
You're doing a Facade design pattern (at least, I think), which is fine, too. We've made the conscious decision to not have the BOs have any association with the DOs at all (at least, ideally. It does sneak in there).