We all know that DataReaders are quicker than DataTables since the a DataReader is used in the construction of a DataTable.
Therefore given that I already have a DataTab
Just call CreateDataReader on your DataTable
There is no existing class that will do this for you. But it shouldn't be hard for you to write a serializable class that implements IDataReader and is a wrapper round your existing DataTable.
EDIT: You might find it easier to inherit from DbDataReader (I think, check the base class of SqlDataReader in object explorer). It provides some of the interface implentation for you. But yes, it is still quite a lot of dull code.
You can't. DataReader and DataTable are two different things.
Since a DataReader enables you to read data as a stream, I don't really see why you want to do this client-side.
A DataReader is typically used to read data from the database and add logic to fill a list of objects or a DataTable. So it's best to do most business logic which has to do with the building of the DataTable on the webservice, pass it to the client as a webservice and work with the other ADO.Net functions there for more business logic.
Maybe you can be more specific on why you really want a DataReader?
A DataReader is the fastest way to read a datastore, but only if certain conditions are met:
Even if these conditions are met by your scenario, the DataReader represents a Connected Datastore, which means that you would need to keep your connection open throughout the time that the DataReader is passed over the network and until the called method at the other end returns some sort of response.
Therefore, it is my opinion that an active DataReader should never be passed around through various layers and applications. I would much rather extract the data into another data store or collection first and dispose of the DataReader immediately.