Один и тот же объект для чтения и хранения результатов

Интерфейс IDataReader наследуется от IDataRecord. Метод Read() изменяет состояние средства чтения, чтобы вы могли получить поля:

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

IDataReader содержит как средство чтения, так и запись. На мой взгляд, это смешивает две проблемы в одном классе. Я бы вернул объект записи и использовал его так:

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

Это разделяет задачи чтения данных и контейнера данных и позволяет выполнять чтение из одного и того же источника с использованием двух потоков.

Мое решение лучше? Каковы некоторые преимущества предоставления читателю возможности содержать результат? Зачем кому-то выбирать подход IDataReader?


.net oop c# design-patterns sqldatareader
person Sjoerd    schedule 12.10.2011    source источник
comment
Единственная причина, о которой я мог подумать, заключается в том, что это позволит избежать создания нового объекта для каждой прочитанной записи (что является плюсом, если обрабатываются очень большие наборы записей).   -  person jgauffin    schedule 12.10.2011
comment
Нестандартный дизайн устройства чтения данных   -  person Sjoerd    schedule 13.10.2011

Ответы (1)


arrow_upward
1
arrow_downward

Одним из недостатков наличия отдельного объекта записи является то, что наивный вызывающий объект может подумать, что он может передать его и использовать независимо от лежащего в основе IDataReader.

т.е. он может подумать, что может получить IDataRecord, пока средство чтения находится на первой записи, и использовать его для ссылки на первую запись, когда средство чтения переместилось или даже было закрыто. Это явно невозможно без накладных расходов на материализацию записи, что противоречит высокопроизводительной концепции чтения только вперед.

Я не претендую на понимание всех мыслительных процессов, лежащих в основе проектного решения, но я уверен, что оно было тщательно продумано и является правильным проектом («правильным» в смысле «наилучшего компромисса», а не «идеального решения»). ').

person Joe    schedule 12.10.2011
comment
Это должно быть оно. Особенно в контексте SQL DataRecord будет заполняться лениво, что требует DataReader. Если вы хотите использовать DataRecord отдельно от DataReader, DataReader должен жадно считывать все поля и больше не может лениво загружать данные. - person Sjoerd; 03.11.2011