Если я понимаю право статьи Katheleen, она предлагает использовать вложенный класс, чтобы быть в состоянии записать SomeEntity. Набор вместо EntityCollection< SomeEntity>. По-моему, это - спорный способ сохранить Вас некоторый ввод. Я вполне уверен, который в наборах приложения реального мира будет иметь некоторое различие в реализациях, таким образом, необходимо будет создать отдельный класс так или иначе. Я думаю, что использование имени класса для ограничения другого объема класса не является хорошей идеей. Это загрязняет intellisense, и усильте зависимости между классами. Используя пространства имен стандартный способ управлять объемом классов. Однако я нахожу, что использование вложенных классов как в комментарии @hazzen приемлемо, если у Вас нет тонн вложенных классов, который является знаком плохого дизайна.
Уловка, заставляющая DataGridView освобождать ресурсы, заключается в выполнении привязки через промежуточный объект BindingSource
.
Тогда код выглядит примерно так:
...
DataGridView dgvQueryResults;
DataTable m_dataTable;
BindingSource m_binder;
public void PopulateView()
{
...
// Bind the data source through and intermediary BindingSource
m_binder.DataSource = m_dataTable;
dgvQueryResults.DataSource = m_binder;
...
}
/// <summary>
/// Frees lindering resources. Sets data bindings to null and forces
/// garbage collection.
/// </summary>
private void ResetDataGridView()
{
dgvQueryResults.DataSource = null;
if (null != m_binder) m_binder.DataSource = null;
m_binder = null;
dataTable = null;
// Force garbage collection since this thing is a resource hog!
GC.Collect ();
m_binder = new BindingSource ();
}
...
Есть ли у вас какие-либо события, зарегистрированные в DataGridView, например OnClick? Убедитесь, что вы отменили регистрацию всех событий, иначе сборщик мусора не будет
Вы закрываете всю форму
? или просто DataGridView
? Мне интересно, есть ли это кеширование в BindingContext
. Вы можете попробовать использовать новый контекст привязки для DataGridView
?
Также; как всегда, события двойной проверки и т. д. - в частности, любое использование захваченных переменных, так как это тонкий способ добавления зависимости (обратите внимание, что области захвата означают, что вы можете захватывать больше, чем вы думаете, если у вас есть сложные анонимные методы / лямбда-выражения).
Возможно, вам придется зайти в профилировщики или windbg, чтобы найти оставшуюся ссылку.