Дня alexdr'у!

S>>Т.е. если хотите получить прекэшированное дерево — сначала забираете весь список, делаете его ToList() /*чтобы кэшировать*/ и делаете по этому списку where простым linq to objects. Вуаля
A>Ну, да. В листинге моего первого сообщения именно так и делается — ToList(). Фрагмент получившегося списка я и привел. C LINQ to Objects поэкспериментирую, спасибо.
Упс. Не добавил — linq to obj использовать для выборки только корней (если в лом чистить список ручками ).

A>Ну, про десктопные приложения я не писал. Наверное, буду думать в сторону DTO, где в них появится необходимость.
Здесь реального опыта нет — ничего не посоветую, сорри

S>>P.P.S. А у вас подразделения в 1 иерархии могут относиться к нескольким организациям? Во люди живут...
A>Нет, подразумевалось, что речь идет о нескольких организациях, каждая из которых владеет своим набором подразделений. Что-то не так с схемой таблицы? Почему возник такой вопрос?

У вас лёгкая денормализация получается — значимые данные (id организации) дублируются по всему дереву подразделений. С одной стороны некритично (шансов что отделы переведутся в другую организацию нет) и даёт возможность быстрой выборки всех подразделений 1 организации. С другой — такой по сути кэш лучше держать отдельно от данных — например, в воспомогательной табличке, обновляемой только по триггеру. Простой пример — нечаянно изменяется айдишник организации только в 1 подразделении. Если не стоит проверка — такое находится только чудом. Поскольку в EF вроде бы нет рид-онли nav props (не гоню, а?) — контроль идёт на откуп клиентам, а тут уж как повезёт.

Если не секрет, как у вас идёт доступ к данным — напрямую к табличкам или через представления/хранимки. Если первое и одни и те же данные будут использоваться несколькими приложениями — я бы задумался.

P.S. Не воспринимайте серьёзно любые советы — никто не знает что у вас за проблема в реальности. Если у вас подразделения — это просто словарик, который в жизни никто не обновит, то всё что я выше написал никакого смысла не имеет.

Удачи!