Я реализовал решение для виртуализации данных, используя некоторые идеи изCodePlex и блогBea Stollnitz и документ Винсента да Вен Берхге (та же ссылка). Однако мне нужен был другой подход, поэтому я решил написать собственное решение.

Я используюDataGrid отображать около миллиона строк с этим решением. Я также использую виртуализацию пользовательского интерфейса. Мое решение выполнимо, но в некоторых ситуациях я наблюдаю странное поведениеDataGrid запрашивает данные из своего источника.

О решении

Я закончил тем, что написал список, который выполняет всю тяжелую работу. Это универсальный класс с именемVirtualList<T>. Он реализуетICollectionViewFactory интерфейс, поэтому механизм создания представления коллекции может создатьVirtualListCollectionView<T> экземпляр, чтобы обернуть его. Этот класс наследует отListCollectionView, Я не последовал советам, чтобы написать свойICollectionView реализация. Наследование, похоже, тоже работает нормально.

VirtualList<T> разбивает все данные на страницы. Он получает общее количество предметов и каждый раз, когдаDataGrid запрашивает строку через индексатор списка, загружает соответствующую страницу или возвращает ее из кэша. Страницы переработаны внутри иDispatcherTimer удаляет неиспользуемые страницы в простое.

Шаблоны запроса данных

The first thing I learned, that VirtualList<T> should implement IList (non generic). Otherwise the ItemsControl will treat it as an IEnumerable and query/enumerate all the rows. This is logical, since the DataGrid is not type safe, so it cannot use the IList<T> interface.

The row with 0 index is frequently asked by the DataGrid. It is seem to be used for visual item measurement (according to the call stack). So, I simply cache this one.

The caching mechanism inside the DataGrid uses a predictable pattern to query the rows it shows. First it asks for the visible rows from top to bottom (two times for every row), then it queries a couple of rows (depending on the size of the visible area) before the visible area (including the first visible row) in a descending order so, from bottom to top. After that it requests for a same amount of rows after the visible rows (including the last visible row) from top to bottom.

If the visible row indexes are 4,5,6. The data request would be: 4,4,5,5,6,6,4,3,2,1,6,7,8,9.

If my page size is properly set, I can serve all these requests from the current and previously loaded page.

If CanSelectMultipleItems is True and the user selects multiple items using the SHIFT button or mouse drag, the DataGrid enumerates all the rows from the beginning of the list to the end of the selection. This enumeration happens via the IEnumerable interface regardless of that IList is implemented or not.

If the selected row is not visible and the current visible area is "far" from the selected row, sometimes DataGrid starts requesting all the items, from the selected row to the end of the visible area. Including all the rows in between which are not even visible. I could not figure out the exact pattern of this behavior. Maybe my implementation is the reason for that.

Мои вопросы

I am wondering, why the DataGrid requests for non visible rows, since those rows will be requested again when become visible?

Why is it necessary to request every row two or three times?

Can anyone tell me how to make the DataGrid not to use IEnumerable, except turning off multiple item selection?