System.Data.SqlClient.SqlDataReader не нравится, хочется get-метод с параметром ColumnName, а не ColumnIndex

Здравствуйте, Firecat, Вы писали:

F>System.Data.SqlClient.SqlDataReader не нравится, хочется get-метод с параметром ColumnName, а не ColumnIndex

В data reader для этого предусмотрен индексатор с параметром типа string.

Здравствуйте, Firecat, Вы писали:

F>System.Data.SqlClient.SqlDataReader не нравится, хочется get-метод с параметром ColumnName, а не ColumnIndex
Хочется — напишите extension метод.
А вообще индексы предпочтительнее и выглядят не хуже, если для хранения индексов использовать переменные с говорящими именами, например так:

int lastNameIndex = reader.GetOrdinal("LastName");
...
string lastName = reader.GetString(lastNameIndex);

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Firecat, Вы писали:

F>>System.Data.SqlClient.SqlDataReader не нравится, хочется get-метод с параметром ColumnName, а не ColumnIndex
S>Хочется — напишите extension метод.
S>А вообще индексы предпочтительнее и выглядят не хуже, если для хранения индексов использовать переменные с говорящими именами, например так:
S>

S>int lastNameIndex = reader.GetOrdinal("LastName");
S>...
S>string lastName = reader.GetString(lastNameIndex);
S>

А ещё проще

int value = reader["LastName"] as int;

Здравствуйте, baranovda, Вы писали:

B>А ещё проще

B>int value = reader["LastName"] as int;

Проще-то оно проще... Однако:
1) Error The as operator must be used with a reference type or nullable type ('int' is a non-nullable value type)

2) допустим, что код выглядит так:

int value = (int)reader["LastName"];

и что в колонке "LastName" хранится что-то целое....
Не факт, что содержимое будет типа int(Int32). В общем случае потребуется конвертация через Coverter. Но в случае с SqlServer об этом можно не беспокоиться, и если колонка типа int, то результат будет приводиться к типу int, чего не скажешь о всех СУБД.

3) Небольшое падение производительности за вызова метода GetOrdinal(string) при каждом обращении к строковому индексатору.

Здравствуйте, samius, Вы писали:

Признаю свою вину — меру, степень, глубину
Я всего лишь хотел напомнить о наличии строкового this[String] у наследников DataReader, а не вступать в академические прения

Здравствуйте, samius, Вы писали:

S>2) допустим, что код выглядит так:

S>int value = (int)reader["LastName"];

S>и что в колонке "LastName" хранится что-то целое....
S>Не факт, что содержимое будет типа int(Int32)…

Почему? Обычно, когда в коде обращения к ридеру известны имена полей, то известен и тип данных, хранящихся там.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

S>>2) допустим, что код выглядит так:
_FR>

S>>int value = (int)reader["LastName"];
_FR>

S>>и что в колонке "LastName" хранится что-то целое....
S>>Не факт, что содержимое будет типа int(Int32)…

_FR>Почему? Обычно, когда в коде обращения к ридеру известны имена полей, то известен и тип данных, хранящихся там.

Обычно, для конкретного провайдера и СУБД — известны. Разные уже могут вести себя по-разному. Однако и GetInt32 здесь не поможет, т.к. он не конвертирует.
Т.е. с пунктом (2) я действительно штангу толкнул

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

S>>2) допустим, что код выглядит так:
_FR>

S>>int value = (int)reader["LastName"];
_FR>

S>>и что в колонке "LastName" хранится что-то целое....
S>>Не факт, что содержимое будет типа int(Int32)…

_FR>Почему? Обычно, когда в коде обращения к ридеру известны имена полей, то известен и тип данных, хранящихся там.

Ну да — там может храниться либо int, либо DBNull. Вставлять проверку на DBNull — код корявый получается. Кстати, проверка на DNNull только по числовому индексу.

Здравствуйте, _d_m_, Вы писали:

S>>>2) допустим, что код выглядит так:
_FR>>

S>>>int value = (int)reader["LastName"];
_FR>>

S>>>и что в колонке "LastName" хранится что-то целое....
S>>>Не факт, что содержимое будет типа int(Int32)…
_FR>>Почему? Обычно, когда в коде обращения к ридеру известны имена полей, то известен и тип данных, хранящихся там.

___>Ну да — там может храниться либо int, либо DBNull.

Обычно, когда в compile-time известен выполняемый запрос (раз уж имена полей известны, то и сам запроc известен), то известен и контракт запроса, а именно: может там быть NULL али нет. А раз это известно при написании метода, то смысл гадать — "там может храниться либо int, либо DBNull"

___>Вставлять проверку на DBNull — код корявый получается.

Не получается, если не полениться и написать хорошие методы-расширения Ведь ничто не мешает делать так:

int? value = reader.AsInt32("LastName");

___>Кстати, проверка на DNNull только по числовому индексу.

Тут я согласен с предыдущими оратарами, высказывшимися в пользу того, что бы после выполнения запроса сначала запросить индексы интересующих полей, запомнить их, а потом уже мотать ридер, пользуясь для чтения данных сохранёнными значениями, так что подобной "проблемы" не вставало никогда. Если религия не позволяет, то методы-расширения спасут и в этом случае.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, _d_m_, Вы писали:

S>>>>2) допустим, что код выглядит так:
_FR>>>

S>>>>int value = (int)reader["LastName"];
_FR>>>

S>>>>и что в колонке "LastName" хранится что-то целое....
S>>>>Не факт, что содержимое будет типа int(Int32)…
_FR>>>Почему? Обычно, когда в коде обращения к ридеру известны имена полей, то известен и тип данных, хранящихся там.

___>>Ну да — там может храниться либо int, либо DBNull.

_FR>Обычно, когда в compile-time известен выполняемый запрос (раз уж имена полей известны, то и сам запроc известен), то известен и контракт запроса, а именно: может там быть NULL али нет. А раз это известно при написании метода, то смысл гадать — "там может храниться либо int, либо DBNull"

Не понял Если все это известно, то вставляется корявенькая проверка на DBNull и все. Как понять гадать? Там может быть либо int, либо DBNull.

___>>Вставлять проверку на DBNull — код корявый получается.

_FR>Не получается, если не полениться и написать хорошие методы-расширения Ведь ничто не мешает делать так:
_FR>

_FR>int? value = reader.AsInt32("LastName");
_FR>

Да я то напишу. Но почему MS-у не написать? Уже 3.5sp1 версия, а обработка DBNull угребищная.

___>>Кстати, проверка на DNNull только по числовому индексу.

_FR>Тут я согласен с предыдущими оратарами, высказывшимися в пользу того, что бы после выполнения запроса сначала запросить индексы интересующих полей, запомнить их, а потом уже мотать ридер, пользуясь для чтения данных сохранёнными значениями, так что подобной "проблемы" не вставало никогда. Если религия не позволяет, то методы-расширения спасут и в этом случае.

Не, ну это понятно, что: "спасение утопающих дело рук самих утопающих".
Когда появились nullable value types — я сначала обрадовался, а потом радость сменилась разочарованием. Хочу заметить, что на VS 2008 перешел только недавно с VS 2005.

Здравствуйте, _d_m_, Вы писали:

___>>>Ну да — там может храниться либо int, либо DBNull.
_FR>>Обычно, когда в compile-time известен выполняемый запрос (раз уж имена полей известны, то и сам запроc известен), то известен и контракт запроса, а именно: может там быть NULL али нет. А раз это известно при написании метода, то смысл гадать — "там может храниться либо int, либо DBNull"
___>Не понял Если все это известно, то вставляется корявенькая проверка на DBNull и все. Как понять гадать? Там может быть либо int, либо DBNull.

"Если всё это известно", то проверки часто не нужны (так как может быть известно что поле не может быть NULL).

Нам, без знания запроса, неправильно укорять автора в отсутствии или необходимости проверок на NULL (так как в некоторых случаях в проверках действительно нет смысла), ибо автор, возможно, уверен в том, что проверки не нужны.