Закрыть и утилизировать - куда звонить?

После прочтения темы Достаточно ли SqlCommand.Dispose? и закрытие и удаление службы WCF Мне интересно, для классов, таких как SqlConnection или одного из нескольких классов, унаследованных от класса Stream, имеет ли значение, если я закрываю Dispose, а не Close?

Я хочу прояснить эту ситуацию.

В соответствии с рекомендациями Microsoft, рекомендуется предоставлять Closeметод там, где это необходимо. Вот цитата из руководящих принципов проектирования Framework

Подумайте о предоставлении метода Close(), в дополнение к тому Dispose(), если близка стандартная терминология в этой области. При этом важно, чтобы вы сделали Closeреализацию идентичной Dispose...

В большинстве случаев Closeи Disposeметоды эквивалентны. Основное различие между Closeи Disposeв случае SqlConnectionObjectсоставляет:

Приложение может вызывать Closeболее одного раза. Никаких исключений не генерируется.

Если вы вызвали Disposeметод, SqlConnectionсостояние объекта будет сброшено. Если вы попытаетесь вызвать какой-либо метод для удаленного SqlConnection объекта, вы получите исключение.

Это говорит:

• Если вы используете объект подключения один раз, используйте Dispose.
• Если объект подключения необходимо использовать повторно, используйте Closeметод.

Как обычно, ответ: это зависит. Разные классы реализуются IDisposableпо-разному, и вы должны провести необходимые исследования.

Насколько SqlClientрекомендуется, рекомендуется делать следующее:

using (SqlConnection conn = /* Create new instance using your favorite method */)
{
    conn.Open();
    using (SqlCommand command = /* Create new instance using your favorite method */)
    {
        // Do work
    }
    conn.Close(); // Optional
}

Вы должны звонить Dispose(или Close*) по соединению! Вы не ждать , пока сборщик мусора , чтобы очистить ваше соединение, это не будет подвязать соединения в бассейне до следующего цикла GC (по крайней мере). Если вы вызываете Dispose, это необязательно Close, и поскольку usingконструкция делает его таким простым для Disposeправильной обработки , на самом деле нет причин для вызова Close.

Соединения автоматически объединяются, и вызов Dispose/ Closeсоединение не физически закрывает соединение (при нормальных обстоятельствах). Не пытайтесь реализовать свой собственный пул. SqlClientвыполняет очистку соединения при его извлечении из пула (например, восстановление контекста базы данных и параметров соединения).

* если вы звоните Close, убедитесь, что вы делаете это безопасным для исключения способом (то есть в блоке catch или finally).

Вам необходимо вызвать Dispose ()!

Dispose () предназначен для вызова разработчиком, сборщик мусора вызывает Finalize (). Если вы не вызываете Dispose () на своих объектах, любые неуправляемые ресурсы, которые они использовали, не будут утилизироваться до тех пор, пока не соберется сборщик мусора и не завершит вызовы для них (и кто знает, когда это произойдет).

Этот сценарий называется недетерминированным финализацией и является обычной ловушкой для разработчиков .net. Если вы работаете с объектами, которые реализуют IDisposable, тогда вызовите Dispose () для них!

http://www.ondotnet.com/pub/a/oreilly/dotnet/news/programmingCsharp_0801.html?page=last

Хотя может быть много случаев (например, в SqlConnection), когда вы вызываете Disponse () для какого-либо объекта, а он просто вызывает Close () для своего соединения или закрывает дескриптор файла, почти всегда лучше всего вызывать Dispose ()! если вы не планируете повторно использовать объект в самом ближайшем будущем.

Ибо SqlConnectionс точки зрения самого соединения они эквивалентны. Согласно Reflector, Dispose()вызовы, Close()а также выполнение нескольких дополнительных операций по освобождению памяти - в основном, путем установки членов равными нулю.

Для Stream они фактически эквивалентны. Stream.Dispose()просто вызывает Close ().

Этот быстрый совет стал длинным ответом. Сожалею.

Как отметил Тайлер в своем хорошем ответе, вызов Dispose()- отличная практика программирования. Это связано с тем, что этот метод должен объединять все необходимое освобождение ресурсов, чтобы не было ненужных открытых ресурсов. Например, если вы записали какой-то текст в файл и не смогли закрыть файл (освободить ресурс), он останется открытым, и никто больше не сможет писать в него, пока GC не придет и не сделает то, что вы должны иметь. сделано.

Теперь, в некоторых случаях будут «финализировать» методы, более специфичные для класса, с которым вы имеете дело, например StreamWriter.Close(), который переопределяет TextWriter.Close(). На самом деле они обычно больше подходят для ситуации: Close()например, StreamWriter сбрасывает поток и базовый кодер перед Dispose()созданием объекта! Прохладно!

Однако, просматривая MSDN, вы обнаружите, что даже Microsoft иногда сбивает с толку множество приближенных и сторонников. На этой веб-странице , например, в некоторых примерах Close()вызывается перед неявным Dispose()(см. Оператор using, если вы не понимаете, почему он неявный), и в одном из них они не беспокоятся. С чего бы это? Я тоже был озадачен.

Причина, по которой я решил (и я подчеркиваю, что это оригинальное исследование, и я, безусловно, могу потерять репутацию, если я ошибаюсь), заключается в том, что он Close()может потерпеть неудачу, приводя к исключению, оставляя ресурсы открытыми, но Dispose(), несомненно, освободит их . Именно поэтому всегда должен защищать в вызов (извините за каламбур).Dispose()Close()

MyResource r = new MyResource();

try {
  r.Write(new Whatever());

  r.Close()
finally {
  r.Dispose();
}

И да, я думаю, что Microsoft воспользовалась этим примером. Возможно, эта временная метка никогда не будет сброшена в файл.

Завтра я исправляю свой старый код.

Редактировать: извините Браннон, я не могу комментировать ваш ответ, но вы уверены, что это хорошая идея, чтобы позвонить Close()в finallyблок? Я предполагаю, что исключение из этого может разрушить остальную часть блока, который, вероятно, будет содержать важный код очистки.

Ответ Браннона: отлично, просто не забывайте звонить, Close()когда это действительно необходимо (например, при работе с потоками - не очень разбирайтесь в соединениях SQL в .NET).

Наберите iDisposable и вызовите распоряжение на это. Это вызовет любой метод, сконфигурированный как реализующий «iDisposable.Dispose», независимо от того, как названа функция.

Обычно мы сталкиваемся с проблемой в Close (), Abort () и Dispose (), но позвольте мне рассказать вам разницу между ними.

1) ABORT: - Я не буду предлагать использовать это, потому что, когда вызывается abort, клиент удаляет соединение, не сообщая серверу, поэтому сервер будет ждать некоторое время (приблизительно 1 мин). Если у вас массовый запрос, то вы не можете использовать abort (), поскольку это может привести к превышению времени ожидания для вашего ограниченного пула соединений.

2) Закрыть: - Закрыть - это очень хороший способ закрыть соединение, потому что при закрытии соединения он вызывает сервер и подтверждает, что сервер тоже закрывается на этой стороне.

Здесь еще одна вещь, чтобы посмотреть. В некоторых случаях, если генерируется ошибка, тогда это не очень хороший способ написать код, наконец, в connection.close (), потому что в это время будет нарушено состояние связи.

3) Утилизировать: - это один из типов закрытия, но после закрытия соединения вы не сможете открыть его снова.

Попробуй так,

private void CloseConnection(Client client)
    {
        if (client != null && client.State == CommunicationState.Opened)
        {
            client.Close();
        }
        else
        {
            client.Abort();
        }
    }