Я должен расположить () DataSet и DataTable?

Вы должны предположить, что он делает что-то полезное, и вызвать Dispose, даже если он ничего не делает в текущем. NET Framework, нет никаких гарантий, что в будущих версиях он останется таким же, что приведет к неэффективному использованию ресурсов.

Если ваше намерение или контекст этого вопроса действительно связаны со сборкой мусора, вы можете явно установить для наборов данных и таблицы данных значение null или использовать ключевое слово using и позволить им выйти за рамки . Dispose не так важен, как сказал ранее Tetraneutron.

Я вызываю dispose каждый раз, когда объект реализует IDisposeable. На это есть причина.

Наборы данных могут сильно занимать память. Чем раньше они будут отмечены для очистки, тем лучше.

update

Прошло 5 лет с тех пор, как я ответил на этот вопрос. Я все еще согласен со своим ответом. Если есть метод удаления, он должен вызываться после завершения работы с объектом. Интерфейс IDispose был реализован неспроста.

Даже если у объекта нет неуправляемых ресурсов, удаление может помочь GC, нарушив графы объектов. В общем, если объект реализует IDisposable, тогда следует вызвать Dispose ().

Действительно ли Dispose () что-то делает или нет, зависит от данного класса. В случае DataSet реализация Dispose () наследуется от MarshalByValueComponent. Он удаляется из контейнера и вызывает событие Disposed. Исходный код приведен ниже (разобран с помощью .NET Reflector):

protected virtual void Dispose(bool disposing)
{
    if (disposing)
    {
        lock (this)
        {
            if ((this.site != null) && (this.site.Container != null))
            {
                this.site.Container.Remove(this);
            }
            if (this.events != null)
            {
                EventHandler handler = (EventHandler) this.events[EventDisposed];
                if (handler != null)
                {
                    handler(this, EventArgs.Empty);
                }
            }
        }
    }
}

Прежде всего я бы проверил, что Dispose делает с DataSet. Возможно, вам поможет отражатель от Redgate.

Наборы данных реализуют IDisposable на основе MarshalByValueComponent, который реализует IDisposable. Так как наборы данных управляются, вызов метода dispose не дает реальной пользы.

Вы сами создаете таблицы данных? Поскольку итерация по дочерним элементам любого объекта (как в DataSet.Tables) обычно не требуется, поскольку задача Родителя - избавиться от всех своих дочерних членов.

Как правило, правило следующее: если вы создали его, и он реализует IDisposable, утилизируйте его. Если вы НЕ создавали его, НЕ удаляйте его, это работа родительского объекта. Но для каждого объекта могут быть особые правила, см. Документацию.

Для .net 3.5 он явно говорит: «Утилизируйте его, когда он больше не используется», так что я бы поступил именно так.

Обновление (1 декабря 2009 г.):

Я хотел бы изменить этот ответ и признать, что исходный ответ был ошибочным.

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

Однако оказывается, что DataSets, DataViews, DataTables подавляют финализацию в своих конструкторах - вот почему вызов Dispose () для них явно ничего не делает.

Предположительно, это происходит потому, что они этого не делают. t иметь неуправляемые ресурсы; поэтому, несмотря на то, что MarshalByValueComponent допускает использование неуправляемых ресурсов, в этих конкретных реализациях нет необходимости, и поэтому можно отказаться от финализации.

(То. б) При выделении (до запуска конструктора) указатель помещается в очередь финализации; c) Завершаемый объект обычно требует восстановления 2 коллекций (вместо стандартной 1); г) Подавление финализации не удаляет объект из очереди финализации (как сообщает! FinalizeQueue в SOS) Эта команда вводит в заблуждение; Знание того, какие объекты находятся в очереди финализации (само по себе), бесполезно; Было бы полезно знать, какие объекты находятся в очереди финализации и по-прежнему нуждаются в финализации (есть ли для этого команда?)

Подавление финализации немного отключается в заголовке объекта, указывая среде выполнения, что не нужно вызывать ее Finalizer (не нужно перемещать очередь FReachable); Он остается в очереди финализации (и о нем продолжает сообщать! FinalizeQueue в SOS)

Все классы DataTable, DataSet, DataView основаны на MarshalByValueComponent, финализируемом объекте, который может (потенциально) обрабатывать неуправляемые ресурсы

• Поскольку DataTable , DataSet, DataView не вводят неуправляемые ресурсы, они подавляют завершение в своих конструкторах
• Хотя это необычный шаблон, он освобождает вызывающего от необходимости беспокоиться о вызове Dispose после использования
• Это и тот факт, что DataTables потенциально могут использоваться в разных наборах данных, уже могу вывести некоторые очень важные вещи:

  Во-первых, объекты, требующие доработки живут дольше, чем предметы, которые этого не делают. На самом деле они могут жить намного дольше. Например, предположим, что объект, находится в Gen2, необходимо доработать. Доработка будет запланирована, но объект все еще находится в gen2, поэтому он будет не собираются повторно до следующего происходит сбор gen2. Это могло быть действительно очень долго, и, по сути, если дела пойдут хорошо, это будет давно, потому что коллекции gen2 дорогостоящие, и поэтому мы хотим, чтобы они случаются очень нечасто. Старший объекты, требующие доработки, могут придется ждать десятки, если нет сотни коллекций gen0 до их пространство возвращается.

  Во-вторых, объекты, требующие доработки причинить побочный ущерб. Поскольку внутренние указатели объектов должны оставаться действителен, не только объекты непосредственно нуждающиеся в доработке задерживаются в памяти, но все объект относится прямо или косвенно к тоже останется в памяти. Если огромный дерево объектов было закреплено один объект, который требовал доработка, потом все дерево будет задерживаться потенциально надолго время, как мы только что обсуждали. это поэтому важно использовать финализаторы экономно и размещать их на предметах которые имеют как можно меньше внутренних объектов указатели по возможности. В дереве пример, который я только что привел, вы легко можете избежать проблемы, переместив ресурсы, нуждающиеся в доработке, в отдельный объект и сохранение ссылка на этот объект в корне дерева. С этим скромным изменением только один объект (надеюсь, хороший маленький объект) будет задерживаться, а стоимость финализации сведена к минимуму.

  Наконец, объекты, требующие доработки создать работу для потока финализатора. Если ваш процесс завершения сложный, единственный и неповторимый поток финализатора потратит много времени на выполнение этих шагов, что может вызвать отставание в работе и поэтому заставляют задерживаться больше предметов ждем доработки. Следовательно, жизненно важно, чтобы финализаторы работают так же мало, как возможное. Помните также, что хотя все указатели объектов остаются действительными во время доработки это может быть случай, когда эти указатели ведут к объекты, которые уже были доработан и поэтому может быть меньше чем полезно. Как правило, безопаснее всего избегайте следующих указателей на объекты в код завершения, хотя указатели действительны. Безопасный, короткий путь завершения кода является наилучшим.

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

  Ссылки:

  1 - http://msdn.microsoft.com/en-us/library/ms973837.aspx

  2 - http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry http://www.dotnetfunda.com/articles/article524-net-best-practice-no-2 -improve-garbage-collector-performance-using-finalizedispose-pattern.aspx

  3 - http://codeidol.com/csharp/net-framework/Inside-the-CLR/Automatic-Memory-Management/