Есть ли какая-нибудь причина для утилизации адаптера стола?

Во многих случаях при работе с различными типами объектов данных важно избавиться от них, чтобы они не открывали соединение с базой данных. Однако адаптеры таблицы не кажутся уязвимыми для этой проблемы, поскольку они построены на принципе отключенных данных. У меня создается впечатление, что адаптер таблицы всегда закрывает его соединение после завершения метода атомарного заполнения или обновления даже при наличии исключений. Это верно?Есть ли какая-нибудь причина для утилизации адаптера стола?

С другой стороны, адаптеры таблицы реализуют IDisposable, поэтому в какой-то момент должны быть некоторые неуправляемые ресурсы для очистки, не так ли? Или это просто церемония, чтобы люди могли написать:

using(var a = new MyTableTableAdapter()) 
{ 
    a.Fill(ds.MyTable); 
}

и не нужно думать об этой теме?

источник

2012-02-09 Paul Keister

Сделайте это и не думайте об этом. –

это в основном, это не повредит вашей работе и избавит вас от беспокойства о 2-м угадывании рамки! –

Если оно реализует IDisposable, оно либо в настоящее время содержит ресурсы для утилизации, либо в будущем. Если это одноразовое, вы должны распорядиться им. Вам не нужно понимать, что это внутренности, - только чтобы понять, что это контракт и чтить его. Как правило, люди не делают ничего из строя - «использование» - это классный синтаксический сахар, но недостаточно холодный, чтобы начать разбрызгивать IDisposable вокруг классов, у которых нет ресурсов для утилизации :)

Также, IDisposable не обязательно означает «неуправляемые» ресурсы. Это означает, что есть ресурсы (например, дескрипторы файлов, сетевые подключения и т. Д.), Которые не являются объектами, которые собираются в мусор (память). Различие - это очистка чего-то не собранного - не неуправляемого. Как раз так бывает, что часто многие из этих ресурсов поддерживаются неуправляемыми ресурсами ОС.

EDIT:

Например, предположим, что я создал полностью управляемый объект, извлеченный некоторые другие объекты из пула (кэш) по требованию, и когда вы закончите использовать его, я хочу, чтобы поместить эти объекты обратно в общий пул (не освобожден - явный вызов добавить что-то в пул. Ничего неуправляемого здесь, но я мог бы вытаскивать объекты из пула по требованию и в распоряжение я мог бы вернуть их (Pool.Add) для других пользователей. Вы, потребитель, просто «использовали» мой объект и знали бы, что он будет очищаться, когда он будет удален. Явный распоряжение необходим, потому что мы не должны ждать завершения (это может произойти позже или совсем не) -

источник

2012-02-09 01:53:16 bryanmac

Не обрабатываются ручки файлов и сетевые соединения? Вот цитата из последних документов: «Основное использование этого интерфейса - освобождение неуправляемых ресурсов». см. http://msdn.microsoft.com/en-us/library/system.idisposable.aspx –

Причина, по которой был создан интерфейс, заключается в «очистке», поскольку сбор мусора должен был собирать объект/память. Как я уже сказал, эти объекты часто поддерживаются ресурсами ОС, которые в конечном счете неуправляемы, но понимают, что все говорят «Первичный» и «Часто». Ультимативно, это избавиться от вещей, когда вы закончите - очистить. – bryanmac

Например, предположим, что я создал полностью управляемый объект, который извлекал некоторые другие объекты из пула, и когда вы закончите использовать его, я хочу, чтобы они вернули эти объекты в общий пул (не освобожден - явный вызов добавить что-то в пул. Ничего неуправляемого здесь, но я мог бы вытаскивать объекты из пула по требованию и в распоряжение, я мог бы вернуть их обратно (Pool.Add), чтобы другие использовали. Вы, потребитель, просто «использовали» мой объект и знали, что он будет очистка при удалении. Явное распоряжение необходимо, потому что мы не должны ждать завершения (это может произойти позже или совсем не) – bryanmac

Есть ли какая-нибудь причина для утилизации адаптера стола?

ответ

Смежные вопросы