Question

The IDataReader interface inherits from IDataRecord. The Read() method changes the state of the reader so that you can retrieve the fields:

var reader = new SomeIDataReader();
while (reader.Read()) {
    var firstField = reader[0];
}

The IDataReader contains both the reader and the record. In my opinion, this mixes two concerns in one class. I would return a record object, and use it like this:

var reader = new MyDataReader();
do {
    var record = reader.Read();
    if (record == null) break;
    var firstField = record[0];
} while (true);

This separates the concerns of data reader and data container, and makes it possible to read from the same source using two threads.

Is my solution better? What are some advantages of letting the reader contain the result? Why would anyone choose for the IDataReader approach?

Answer 1

One disadvantage of having a separate record object is that a naive caller might think he could pass it around and use it independently of the underlying IDataReader.

I.e. he might think he could get an IDataRecord while the reader is positioned at the first record, and use it to reference the first record when the reader has moved on or even been closed. This is patently impossible without the overhead of materializing the record, which goes against the high-performance forward-only concept of a reader.

I don’t pretend to understand all the thought processes that went into the design decision, but I’m sure it was carefully considered and is the right design (‘right’ in the sense of ‘best trade-off’ rather than ‘perfect’).