views:

1754

answers:

4

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 DataTable.... Why would I want to convert it to a DataReader?

Well I am creating an internal interface called IDataProvider. This interface is intended to be implemented both locally and as a WebService. The interface will have a method "Getdata" which takes some criteria information and returns some data.

Since a DataReader is the quickest data retrieval mechanism, I will want to use this as the result type of the "GetData" method. However we also know that the DataReader is not serializable and therefore cannot be transferred across the web via a web service...

In the case of the web I would have the local proxy class request the data as a DataTable and then transform it locally into a DataReader.

In this way the Local application need not know (or care) that if it is accessing the data locally or remotely.

However in order to do this I need to know... How do I wrap a DataReader around a preexisting DataTable?

Update: My business logic is not going to be held in the webservice since the DataProvider that uses the Webservice is switchable for one which does not. The businessLogic will therefore be held in the client app.

FWIW I am using .Net 3.5 SP1

A: 

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?

Gerrie Schenck
I chose the DataReader because it's the fastest mechanism. The webservice is not going to contain any BusinessLogic (Except **maybe** a custom security layer)
Rory Becker
+1  A: 

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.

pipTheGeek
Thanks very much that's just what I was after.
Rory Becker
Damn that's an involved interface.
Rory Becker
+1  A: 

A DataReader is the fastest way to read a datastore, but only if certain conditions are met:

  1. The data is to be read in a forward-only manner.
  2. The data is to be read-only.

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.

Cerebrus
In the case of the Local DataProvider these conditions would all be met. In the case of the WebdataProvider, the conditions are also all going to be met. The new Datareader will only be used in a readonly forward moving fashion.
Rory Becker
I would hope to have the Datareader *connect* to the DataTable and therefore be quite happy in itself.
Rory Becker
+6  A: 

Just call CreateDataReader on your DataTable

Erm ... really embarrassed.... how in the h*ll did I miss that? Thanks very much
Rory Becker
@Rory, these things are not always obvious. There are too many to know them all. That is why we have StackOverflow.
dboarman