IDisposable, Финализаторы и определение неуправляемого ресурса

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

using (var myObj = new Whatever())
{
   // ..
}

похоже на

{
  var myObj;
  try
  {
     myObj = new Whatever();
     // ..
  } 
  finally
  {
    if (myObj != null)
    {
      ((IDisposable)myObj).Dispose();
    }
  }
} // object scope ends here

EDIT : добавлено try / finally благодаря Talljoe - вау, это сложно поймите это правильно :)

EDIT2: Я не говорю, что вы должны использовать второй вариант. Я просто хотел показать, что «использование» - хороший синтаксический сахар для кучи кода, который может стать довольно беспорядочным и трудным для правильного выполнения.

Вы всегда должны вызывать Dispose для объектов, реализующих IDisposable (если только они специально не сообщают вам, что это полезное соглашение, например HtmlHelper.BeginForm в ASP.NET MVC). Вы можете использовать оператор using, чтобы упростить это. Если вы используете ссылку на IDisposable в своем классе в качестве поля-члена, вам следует реализовать IDisposable, используя Disposable Pattern , чтобы очистить эти элементы. Если вы запустите инструмент статического анализа, такой как FxCop, он скажет вам то же самое.

Вы не должны пытаться предугадывать интерфейс. Сегодня этот класс может не использовать неуправляемый ресурс, но как насчет следующей версии?

Вы не несете ответственности за содержимое объекта. Dispose () должен быть прозрачным и освобождать то, что ему нужно. После этого вы не несете за это ответственности.

Неуправляемые ресурсы - это ресурсы, которые вы создали бы в (управляемом) C ++, где вы распределяете память с помощью указателей и «новых» операторов, а не операторов «gcnew». Когда вы создаете класс на C ++, вы несете ответственность за удаление этой памяти, поскольку это внутренняя память или неуправляемая, и сборщик мусора не об этом. Вы также можете создать эту неуправляемую память с помощью выделения Marshal и, i ' Предполагается, что это небезопасный код.

При использовании Managed C ++ вам также не нужно вручную реализовывать класс IDisposable. Когда вы напишете свой деконструктор, он будет скомпилирован в функцию Dispose ().

Здесь не хватает финализатора. Моя привычка заключалась в том, что если я реализую IDisposable, у меня также есть финализатор для вызова Dispose () на случай, если мой клиент этого не сделает. Да, это добавляет накладные расходы, но если вызывается Dispose () IS, то вызов GC.SuppressFinalize (this) устраняет его.

Если класс, о котором идет речь, предоставлен Microsoft (например, база данных и т. д.), то обработка Dispose (из IDisposable), скорее всего, уже будет выполнена, вам остается только ее вызвать. Например, стандартная практика использования базы данных будет выглядеть так:

//...
using (IDataReader dataRead = new DataReaderObject())
{
   //Call database
}

По сути, это то же самое, что писать:

IDataReader dataRead = null;
try
{
    dataRead = new DataReaderObject()
    //Call database
}
finally
{
    if(dataRead != null)
    {
        dataRead.Dispose();
    }
}

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

Что касается использования IDisposable самостоятельно, реализация зависит от вас. После того, как вы унаследуете его, вы должны убедиться, что метод содержит код, необходимый для удаления любых подключений к БД, которые вы могли создать вручную, освобождения ресурсов, которые могут остаться, или предотвращения уничтожения объекта, или просто очистки больших пулов ресурсов (например, изображений ). Это также включает в себя неуправляемые ресурсы, например, код, помеченный внутри «небезопасного» блока, по сути, является неуправляемым кодом, который может допускать прямые манипуляции с памятью, что определенно требует очистки.

После того, как вы унаследуете его, вы должны убедиться, что метод содержит код, необходимый для удаления любых подключений к БД, которые вы могли создать вручную, освобождения ресурсов, которые могут остаться, или предотвращения уничтожения объекта, или просто очистки больших пулов ресурсов (например, изображений ). Это также включает в себя неуправляемые ресурсы, например, код, помеченный внутри «небезопасного» блока, по сути, является неуправляемым кодом, который может допускать прямые манипуляции с памятью, что определенно требует очистки.

После того, как вы унаследуете его, вы должны убедиться, что метод содержит код, необходимый для удаления любых подключений к БД, которые вы могли создать вручную, освобождения ресурсов, которые могут остаться, или предотвращения уничтожения объекта, или просто очистки больших пулов ресурсов (например, изображений ). Это также включает в себя неуправляемые ресурсы, например, код, помеченный внутри «небезопасного» блока, по сути, является неуправляемым кодом, который может допускать прямые манипуляции с памятью, что определенно требует очистки.

Почему это должно иметь для вас значение?

По возможности я оборачиваю объем одноразового предмета в using. Это вызывает dispose в конце использования. В противном случае я явно вызываю утилизацию всякий раз, когда объект мне больше не нужен.

Не требуется по причине 1 или по причине 2.