Проблемы ТС, похоже, совсем не в асинхронных вызовах.
Но поскольку зашел разговор о классификаторах, то надцать callback'ов для них в viewmodel - вариант решения в лоб

Denis.Не стоит притягивать за уши то чего сказано не было. Например на вопрос "почему не вытянуть нужные данные сразу, а не делать кучу вызовов" можно найти 1000 правильных вариантов ответа почему так делать не стоит, но суть поста была не почему так делать не надо, а как это можно сделать если это надо. И не надо мне доказывать что синхронный вызов метода не правилен по такому то паттерну. Это чушь. Где то это правильно, где то нет.

А в синхронных вызовах кучу данных тоже никто не возращает за один раз.
Нет никаких сложностей в асинхронных кроме привычек.

ЗЫ Вопрос поставлен совершенно невнятно.

МСУ, а с чем ты можешь согласиться, если кроме callback'ов ничего не видел, не знаешь и не пробовал?
Возможен общий вариант, когда про работу с БД можно забыть и не вспоминать, сделав один раз.
Модератор: Сева, по-легче с аллегориями

Изучай LightSwitch. Твои ItemN и так до бесконечности даже в WPF c cинхронными вызовами - решение в лоб, берем лопату и копаем.
Есть совершенно другие

МСУiИзучай LightSwitch. Твои ItemN и так до бесконечности даже в WPF c cинхронными вызовами - решение в лоб, берем лопату и копаем.
Есть совершенно другие
Ты ваще в вакууме или просто тупишь?

Я говорю за то, что на клиенте асинхронно "ItemN" юзать - лапшекодно и не есть бест практис, очнись. А вот на сервер сайд (WCF) эти "ItemN" мы будем юзать синхронно, как полагается. Если нужно, вынесим в отдельный блок (метод) набор "ItemN", если еще где используется эта логика. А для клиента мы в результате получим нормальный единоразовый асинхронный врап.
Выборка данных используется везде и всюду. "Отдельный блок" - шаблон Repository. Если он нормально сделан, то нет никакой разницы какие там вызовы. Item1 ... Item2 в ViewModel жирно перечеркиваем, создаем ViewModelLocator, c ним можно загружать нужные классификаторы напрямую из XAML.
Можно иметь нормальную архитектуру или кричать о кривизне рук индусов и всю жизнь ковыряться в обработчиках и callback'ах, изобретая собственные велосипеды.

МСУ, расставание с обработчиками событий - трудный процесс для некоторых.

МСУiМСУ, расставание с обработчиками событий - трудный процесс для некоторых.
Проблема заключается в том, что с ними никто не собирается расставаться. MVVM - это дешёвка и бред. Мы с Дениской (другим, не ТС) уже объясняли это. MVVM + MVC(P) - это да, хороший съедобный вариант.

Да ничего вы не объяснили, а продемонстрировали только, что шаблоны еще нужно правильно применять с учетом возможностей технологии, иначе, действительно, конфуз получается

iscrafmViPRosпропущено...

а лукапы?
также. Загружается только видимая информация. Если не воспользовались никакими из десятков лукапов или деталей, то они так и останутся незагруженными.

А если нужно вытащить сразу весь граф объекта (Root->Child->GrandChild->etc) сидим и тоскливо наблюдаем, как неспешно идут запросы.