С таким количеством узлов, даже если вы сможете найти эффективный способ их отображения, ваши пользователи вряд ли смогут его использовать. Представьте, что вы пытаетесь прокрутить 35 000 узлов, чтобы найти интересующий вас узел! То же самое касается пейджинга. Действительно ли пользователь пойдет на страницу 3500 страниц (при условии, что размер страницы равен 10), чтобы найти свою цель? Вероятно, нет, и если они это сделают, они, вероятно, не будут слишком счастливы. :)
Вместо этого, с такими большими наборами данных, я нахожу, что лучше всего обеспечить некоторый тип пользовательского интерфейса «Фильтр». То, что позволяет вашему пользователю «преобразовать» доступные данные в более управляемую коллекцию.
Я не уверен, какую способность вы можете предоставить для фильтрации (то есть, по каким полям вы можете фильтровать), но я думаю, что это ваш лучший выбор. Варианты интерфейса:
- Что-то вроде RadGrid для ASP.NET AJAX, который может обеспечить встроенный пользовательский интерфейс фильтрации, который позволяет пользователям быстро находить интересующие их значения.
- Используя клиентский API RadTreeView и поддержку загрузки узлов по требованию, вы можете создать текстовое поле, которое будет фильтровать узлы в дереве по типу пользователя. Вы просто обработаете событие onkeyup TextBox, а затем отправите запрос в веб-службу, чтобы получить узлы, которые соответствуют критериям фильтра, и замените коллекцию узлов TreeView на результат. Это упростит для пользователей намного поиск целевого узла.
Очевидно, что есть и другие подходы, но, надеюсь, это даст вам некоторые идеи.
Краткий ответ: Для больших наборов данных я бы использовал комбинацию фильтрации в реальном времени и веб-сервисов, чтобы предоставить пользователям более управляемый набор результатов. Для начальной загрузки я бы загружал только первые (скажем) 200 узлов, чтобы поддерживать высокую производительность.
Надеюсь, это поможет!
-Todd