WPF алтернатива за виртуализация

Има ли алтернатива за виртуализация на WPF, при която контейнерите за всички елементи се генерират (така че обвързванията се оценяват), но се свиват, докато не се виждат (така че няма допълнителни разходи за изобразяване/оформление)?

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

Идеята ми е да имам алтернативен ScrollViewer, който автоматично свива всички елементи, които не се виждат (и ги прави видими отново, когато се виждат), но все пак показва палеца в очакваната позиция (и с очакваната височина).

Някой знае ли съществуващо решение за това?


person LionAM    schedule 13.08.2015    source източник
comment
Каква функционалност ви трябва, която е свързана със свойство на зависимост? Имате всички елементи в модела на изглед, не можете ли да използвате обектите там, за да получите това, което искате?   -  person Adrian Fâciu    schedule 13.08.2015
comment
Бих искал да имам функционалността в рамките на някакъв GridView компонент. Той автоматично управлява групирането и сортирането на елементите (ViewModel не е включен), но не актуализира групирането/сортирането, ако някое свойство в ViewModel се промени. Мога да открия промяната чрез прикачено свойство - това обаче работи само ако са създадени съответните клетки.   -  person LionAM    schedule 13.08.2015


Отговори (1)


Най-добрият начин за справяне с тези проблеми е да разчитате на модела MVVM. Всички зависимости ще се управляват от Model/ViewModel, но не от страната View

person tafia    schedule 13.08.2015
comment
Благодаря за мнението. Трябва обаче да не се съглася: когато има някаква функционалност, която може да се обработва универсално чрез промяна на само един стил на някой WPF компонент - защо трябва да го правя може би 20 пъти във всички ViewModels, които се консумират? Мисля, че това би било много податливо на грешки. - person LionAM; 13.08.2015
comment
Не съм сигурен, че разбрах какво имаш предвид под 20 пъти. На практика ViewModel може просто да наследи друг ViewModel, така че да направите само 1 промяна. Разсъждението за това как показва СРЕЩУ как се променят данните ми изглежда по-склонно към грешки. Но отново предполагам, че е така, защото съм свикнал повече с по-късно. - person tafia; 13.08.2015
comment
ViewModels нямат абсолютно нищо общо, освен че това са списъци с обекти, които се представят с помощта на някакъв (външен) GridView компонент. Компонентът вече поддържа групиране/сортиране, но не актуализира това, ако се промени някое свойство на ViewModel (или което и да е дете, което е обвързано с колона на GridView). Така че наследството всъщност не е опция... - person LionAM; 13.08.2015