Paul's option is a good one and it does save the overhead of instantiating another business object.But, a business object can store data that does not match it's strong-typed properties, so you could really use any business object and fill it. Just don't go trying to access those strong-typed properties that don't have a backing field, or you'll get a nice exception
Using Paul's option is cleaner.
Oh, and there's also the CopyDataFrom() and MergeDataFrom() overloads that accept DataTable parameters if you won't want to use the Load method directly on the CurrentDataTable.