Использование использования для удаления вложенных объектов

да. Вы могли бы немного очистить это

using (SqlConnection conn = new SqlConnection(sqlConnString))
using (System.Data.SqlClient.SqlCommand cmd = new System.Data.SqlClient.SqlCommand())
{
   // code here
}

Но вам все равно понадобится using для каждого объекта IDisposable.

Изменить: рассмотрим этот пример not с использованием внутреннего оператора using.

class A : IDisposable
{
    public void Dispose()
    {
        Console.WriteLine("A Disposed");
    }
}

class B : IDisposable
{
    public void Dispose()
    {
        Console.WriteLine("B Disposed");
    }
}

Код

using (A a = new A())            
{
    B b = new B();
}

В конце блока правильно расположена буква A. Что происходит с B? Что ж, это выходит за рамки и просто ждет сборки мусора. B.Dispose () не вызывается. С другой стороны

using (A a = new A())
using (B b = new B())
{
}

Когда выполнение покидает блок (фактически, блоки), скомпилированный код выполняет вызовы метода Dispose () каждого объекта.

Вы должны вызвать dispose для обоих, однако его будет легче читать, если вы просто сделаете это:

using (SqlConnection conn = new SqlConnection(sqlConnString)) 
using (SqlCommand cmd = new SqlCommand()) 
{ 
     cmd.CommandType = CommandType.Text; 
     cmd.CommandText = cmdTextHere; 
     conn.Open(); 

     cmd.Connection = conn; 
     rowsAffected = cmd.ExecuteNonQuery(); 
} 

поскольку создается неявный блок (например, оператор if или оператор for) и поскольку using представляет собой весь блок, фигурные скобки не нужны, и, на мой взгляд, он выглядит аккуратнее. Некоторые скажут, что вы всегда должны использовать фигурные скобки, потому что слишком легко случайно добавить второй оператор и создать ошибку, но в данном случае я думаю, что это маловероятно.

Вы можете не использовать символы вокруг SqlCommand. ГХ в конечном итоге очистит это за вас. Однако я настоятельно не рекомендую этого делать. Я объясню почему.

SqlCommand косвенно наследуется от System.ComponentModel.Component и, следовательно, наследует его Finalizer метод. Отсутствие вызова dispose для SqlCommand гарантирует, что команда будет продвинута по крайней мере на одно поколение после того, как она выйдет из области видимости (сборщик мусора .NET - это generational gc). Например: когда команда была в первом поколении, она перейдет в поколение 2. Финализируемые объекты дольше хранятся в памяти, чтобы финализатор мог безопасно работать. Но не только сама команда хранится в памяти, но и все объекты, на которые она ссылается, передаются этому поколению. Объекты, на которые он будет ссылаться, - это SqlConnection, список SqlParameter объектов, возможно большая строка CommandText и многие другие внутренние объекты, на которые он ссылается. Эта память может быть удалена только при сборе этого поколения, но чем выше поколение, тем реже оно очищается.

Таким образом, отказ от вызова вызовет дополнительную нагрузку на память и дополнительную работу для потока финализатора.

Когда .NET не может выделить новую память, среда CLR принудительно выполняет сборку мусора всех поколений. После этого в среде выполнения обычно снова будет достаточно места для размещения новых объектов. Однако, когда этот принудительный сбор происходит, когда в памяти есть много объектов, которые все еще необходимо повысить до следующего поколения (поскольку они финализируемы или на них ссылается финализируемый объект), возможно, что CLR не может освободить достаточно памяти. Результатом этого будет OutOfMemoryException.

Должен признаться, я никогда не видел, чтобы это происходило, потому что разработчики распоряжались не только своими SqlCommand объектами. Однако я часто видел OOM в производственных системах, вызванных неправильным удалением объектов.

Я надеюсь, что это дает немного информации о том, как работает сборщик мусора и каков риск неправильной утилизации (финализируемого) объекта. Я всегда выбрасываю все одноразовые предметы. Хотя взгляд в Reflector может доказать, что это не обязательно для определенного типа, такой тип программирования приводит к тому, что код менее удобен в обслуживании и заставляет код зависеть от внутреннего поведения типа (и это поведение может измениться в будущем).

Чтобы ответить на ваш вопрос, да, вы можете это сделать.

Поскольку объект SqlCommand ограничен внешними скобками, он будет собран сборщиком мусора, когда выполнение выйдет за пределы блока.

Другие ответы тоже допустимы, но они не дали точного ответа на ваш вопрос :)