As an alternative to DataSet, you can design your ADO.NET application around DataReader. DataReader is meant for reading a stream of data directly from the command object while connected to the data source.
Microsoft recommends the use of DataReader for applications in which:
Users need quick one-time data access in read-only and forward-only fashion.
Data caching is not required.
You are processing results that are too large to fit into memory.
Yet even the relatively simple DataReader is fraught with some complexity. "Only one DataReader can be open at a time, off a single connection. In ADO, if you opened a single connection and requested two Recordsets that used a forward-only, read-only cursor, ADO implicitly (opened) a second unpooled connection to the data store for the life of that cursor, and then implicitly (closed) it," according to Microsoft's Lu and Rothaus.
With ADO.NET, Lu and Rothaus say, "If you want two DataReaders open at the same time, off the same data store, you have to explicitly create two connections, one for each DataReader."
Also, DataReader is incapable of being remoted between tiers. Moreover, DataReader must be closed before it can access any output parameters from the associated command.