user7320Алексей Кпропущено...
У Джоша Смита подход так себе. Для загрузки детей дерева нужен аналог Lazy<T> с реализацией INotifyPropertyChanged. Вот моя асинхронная реализация.
У Джоша ленивая загрузка.Тут тоже. Только у него загрузка по изменению свойства IsExpanded, а у меня при первом обращении к свойству Value. Так гибче, можно применять не только для дерева.

user7320Я только с твоим async не понял, как она реализуется. Через другой поток?Какой Task создашь - через такой поток и будет. См "Асинхронные ленивые свойства" .

user7320А если асинк не нужен, то всё нормально?Тут асинк не имеет значения. Можно сделать без него. Но с ним лучше.

user7320А я и так байню свои модели представления на TreeViewItemДа. Но вопрос, накой тут ещё одна универсальная прослойка, когда есть TreeViewItem.

мсущкоАлексей, а так не комильфо? http://codearticles.ru/articles/2087 Почему без async?

user7320А у тебя я почитал - куча бесполезных для меня букв.Я предлагал прочитать пару абзацев про UiAsyncLazyProperty<T> и сравнить его с родным Lazy<T>.

user7320Вот, например:

авторСуществует два основных способа создания пар ViewModel-View, на основе которых строятся фрагменты пользовательского интерфейса:

и дальше описание этих способов.

Ты это сам писал? Ты до этого из своего опыта дошёл и все классы, типа UiResource и т. п., сам написал, или всё передрал у кого-то?К сожалению, сам. Набив при этом не мало шишек и выбросив кучу кода в золотую корзину.

user7320Если сам, то это, по-видимому, только тебе и поможет. Другой человек, даже если и применяет что-то подобное, наверняка в твоей писанине разбираться не будет - он по-своему это всё понимает и вникать в чужую точку зрения, особенно, если она представляет из себя тонны кода и страниц с описаниями, ему просто неохота.Мне в своё время не хватало подобного примера. Весь инет завален хэлоувордами, на первый взгляд красивыми, но неприменимыми в серьёзном проекте. Мой же пример реализации показывает как это выглядит во вполне реальном проекте, не слишком большом и не слишком маленьком. А этот мануал используется в первую очередь для обучения наших программистов. А раз уж он есть, я его решил опубликовать. С одной стороны мне могут указать на ошибки, с другой - это, как я думаю, действительно может оказаться кому-то полезным.

user7320А уж тем более, если этот человек как я, который и не понимает, зачем всё это нужно.

Поэтому лучше отвечать на конкретную проблему новичка, чем сразу вываливать на него какой-нибудь монструозный "энтерпрайз-подход", который чтобы понять, надо ещё кучу тем поднять и изучить.С этим не спорю, материал рассчитан на подготовленного читателя. Я специально не стал писать на общеизвестные темы, этой информации и без меня хватает.

user7320мсущкопропущено...

Асинкодрочеры, блин :)
Перфекционисты, тудыть их сюдыть...

Зачем асинки для жалких пары сотен айтимов максимум в дереве?Когда при открытии формы у тебя из UI-потока будут последовательно синхронно запускаться с десяток мелких запросов к вебсервису, поверь, это более чем заметно.

мсущкоАлексей КПочему без async?
Асинкодрочеры, блин :)В убогом JS всё асинхронно. А мы чем хуже?

user7320Ну, если это запросы к потенциально тормозящим репозиториям, то да. Но ты, как я понял, используешь эти асинки и лейзи вездеЛюбое обращение к серверу потенциально тормозящее.
user7320даже если надо из ОЗУ достать и показать десяток айтимов?Ну и что? Там применяется Task. Его можно запустить четырьмя способами:

1. Thread Pool.
2. New Thread.
3. UI Thread.
4. I/O Completion port.

Так же можно произвести расчёт синхронно и вернуть завершённый Task с помощью метода Task.FromResult.

мсущкоАлексей КВ убогом JS всё асинхронно. А мы чем хуже?
Ну если ты о аяксе, то да.Да, о Аяксе.

мсущкоПросто там всё сложнее, есть песочница в виде браузера, браузер - это не только твоё приложение, но и 100500 остальных. А когда в руках целая песочница, то надобность асинка в разы ниже.И там и тут надобность одинаковая. И там и тут есть UI-поток, который нельзя блокировать длительными обработчиками. Повторюсь, любое обращение к серверу - это (потенциально?) длительная операция.

мсущкоПросто нынче асинк "моден", вот ты его куда надо и не надо мастыришь. Ну ведь признайся, эффект обезьянок на лицо.Кто бы говорил, любитель вьюмоделей. :-)

мсущко Чрезмерное обобщение - это болезнь.Добавил... Во всём надо знать меру.

мсущкоТак вот зачем мне городить петрушку асинковДа какая там петрушка, там работы на 5 минут.

мсущкоесли проблема кроется в том, что в табличке БД отвалился индекс и всё стало раком.Одно другому не мешает. Но повторюсь, с десяток синхронных мелких запросов к вебсервису при открытии формы очень даже заметны. Их параллельный асинхронный запуск решает проблему.

мсущкоАлексей Кпропущено...
Добавил... Во всём надо знать меру.
100%, но в данной задаче имхо нечего обобщать, в дерево может хоть кто угодно.Да

мсущкоАлексей К Но повторюсь, с десяток синхронных мелких запросов к вебсервису при открытии формы очень даже заметны. Их параллельный асинхронный запуск решает проблему.
А зачем столько много обращений? Многовато...Можно по одному на комбобокс. Можно подтянуть список а потом лениво подтягивать детализацию по каждой записи. Всякое бывает.

мсущкоАлексей КМожно по одному на комбобокс. Можно подтянуть список а потом лениво подтягивать детализацию по каждой записи. Всякое бывает.
А почему не хочешь одну большую модель выплёвывать из сервиса для каждой формы? Ну а дальше уже на клиенте - через вью модель и в mvvm. Производительность вырастет в разы.Пробовали так. Не понравилось. Приходится писать много букв. Да и не все задачи можно решить таким образом.