13

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

Fabian Steeg
  • 44,988
  • 7
  • 85
  • 112
Rory Becker
  • 15,551
  • 16
  • 69
  • 94
  • 2 Downvotes anyone care to comment why? – Rory Becker Jan 26 '09 at 12:11
  • Probably because you only state you want to use a DataReader because you think it will help you with performance. More information on the setup of your application, why you want to use the DataReader instead of a DataTable and where your business logic resides might be helpful. – Gerrie Schenck Jan 26 '09 at 12:13
  • Business-Logic resides in the Client Application. – Rory Becker Jan 26 '09 at 12:20
  • Not sure what to tell you about reasons for Datareader...My choices are 1.> DataTable/Dataset 2.> Custom Structure. 3.> Datareader. Since 1 and 2 require the use of 3 in all cases, 1 & 2 must be slower. therefore I chose 3 as the defacto transfer mechanism. Is this Wrong? – Rory Becker Jan 26 '09 at 12:21
  • If you're truly worried about it, hide the implementation details behind a facade so you can optimize your code without having to modify your consumers. That might be a little harder, however. You might want to look into linq-ifying your comms: IQueryable rather than IDataReader. –  Jan 26 '09 at 12:52
  • Generally I understand "premature optimization", but here I'm not doing extra work to perform the optimization. I'm avoiding extra work by 'Optimizing'. Creating a facade around SQLDatareader for no reason other than abstraction seems like extra unneeded work. Isn't IDataReader already good enough? – Rory Becker Jan 26 '09 at 13:13
  • @Will - IQueryable = Interesting :) – Rory Becker Jan 26 '09 at 13:14
  • RE: Knuth - Donald Knuth - # “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”[4] - Donald Knuth – Eli Feb 03 '09 at 23:25

4 Answers4

33

Just call CreateDataReader() on your DataTable

Dmitry Bychenko
  • 180,369
  • 20
  • 160
  • 215
  • 6
    @Rory, these things are not always obvious. There are too many to know them all. That is why we have StackOverflow. – IAbstract Aug 31 '10 at 20:14
1

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
  • 25,615
  • 8
  • 56
  • 70
  • 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 Jan 26 '09 at 12:46
  • I would hope to have the Datareader *connect* to the DataTable and therefore be quite happy in itself. – Rory Becker Jan 26 '09 at 12:47
0

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
  • 2,703
  • 17
  • 16
-2

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
  • 22,148
  • 20
  • 68
  • 95
  • 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 Jan 26 '09 at 12:24