Creating my own DataReader like TCP Client/Server

I'm not even sure where to start. I would like to create something like the ADO DataReader but that works in a TCP Client/Server scenario.

Basically, in the TCP Client, I want to be able to call a certain command in the TCP Server which will return a DataReader like object, which I can then iterate through such as:

while dr.Read

from the client. In each loop, I would parse out the various fields as in a normal DataReader.

The reason I want to do this is to gain the inherent efficiency of the DataReader object since it doesn't first load ALL of the data. To my understanding, the typical TCP Client/Server setup using streams, would first load all of the data on the server, then transport ALL of that data to the client for processing. I want to avoid that, and just stream the data as the client requests through the Read() command which means the connection will remain open to the server while the Read() command is being issued by the client, or until explicitly closed by the client.

Hopefully this makes sense and someone can point me in the right direction. Thanks!

ADO.NET is designed specifically so that it's easy for third-parties to create their own ADO.NET provider. There are interfaces and base classes in the System.Data namespace that you can use as the basis of your own full or partial ADO.NET provider.

In your case, you want to inherit the DbDataReader class. For an example, check out the DataTableReader class, which exposes the contents of a DataTable via a DbDataReader. I'd start out by reading the documentation for the DbDataReader class and then creating my own derived class. If you're not sure how to proceed, check out the documentation for the DataTableReader class and maybe the implementation through .NET Reflector.

Interesting. But could I get this to work over TCP/IP? Is it flexible enough to use a custom transport?

Quote:

---

Originally Posted by dbassettt74

Interesting. But could I get this to work over TCP/IP? Is it flexible enough to use a custom transport?

---

It's up to you to provide the implementation so it can do absolutely anything that you want it to do.

Why a datareader over TCP? It seems to me that it might defeat the advantage of the datareader over a datatable. As far as I can see, the advantage that the datareader has is speed. It reads pretty much on demand, one row at a time, and is forward only, read only. If you push it across a TCP connection, what is it that you actually intend to push? One record at a time? More? In either case, it seems like a WCF service returning all or parts of a datatable might prove to have the same performance as a datareader exporting rows through TCP. The advantage of the WCF service is that it is much more standard.


Therefore, I would ask what benefits or characteristics you expect to see from a datareader over TCP?

Through my experience with WCF, it is very slow. I think there is just too much extra overhead with WCF/.NET Remoting. I'm trying to create a very lightweight TCP Client/Server service which attempts to use the same paradigm as a DataReader. I really think it would be efficient. The "back-end" data, is not necessarily a database as you think. It could be custom objects cached on the server side. I'm just trying to figure out a way to marshal them to the client, and I really like the idea of a DataReader type paradigm, where it is forward only, one row at a time, as the client requests it. In contrast to that, I think a typical TCP Client/Server setup is one in which ALL of the data is "packaged" up into a stream on the server, and then passed over the wire to the client, at which time the client disassembles ALL of the data into some object and then iterates over that data. I think that is too heavy and slow.