я столкнулся такие ситуации, когда ваш код будет гарантированно генерировать ровно один единственный результирующий ряд, и я склонен согласиться с тем, что инстанцирование счетчика для этой строки не является идеальным. Фактически, я видел несколько приложений, в которых использовались однорядные (или даже одноколонные) результирующие множества, и авторы писали несколько очень простых методов класса-оболочки, которые были предназначены для выполнения произвольного запроса с одним результатом и возврата он в один звонок, упаковывая накладные расходы на вызов, параметры и т. д. в аккуратном, чистом одиночном методе.
В этом случае я на самом деле думаю, что это хороший случай, чтобы проверить свойство Count для строк, и если его не один, выбросьте исключение. Если у вас есть запрос, который навсегда и всегда должен возвращать ровно одно значение, но еще больше, что-то не так.
if (objDT != null && objDT.Rows.Count != 1)
{
DataRow x = objDT.Rows[0];
var value1 = x["column1"]; // and so on
//..do whatever
}
else
{
if (objDT==null)
{
throw new InvalidOperationException("No data returned");
}
if (objDT.Rows.Count != 1)
{
throw new InvalidOperationException("Multiple values returned where only one expected.");
}
}
Я не совсем понимаю, что вы ищете. У вас есть этот первый пример кода - что именно не так с ним? – Oded
Еще один разработчик, более старший, чем я посмотрел на некоторый код и критиковал подход перечисления данных, потому что только один ряд был бы возвращен (гарантирован) базовым запросом. Я не понимаю, что такое альтернатива (должен использовать DataTable). – w0051977
IMO мнение другого разработчика полностью субъективно. Возможно, * not *, полагающийся на запрос, только когда-либо возвращающий одну строку, является лучшим/более защитным программированием, чем если бы он всегда возвращал точно один. ETA Я вижу, что DavidW одновременно сделал то же самое в своем втором параде – peterG