Z>Я так и не услышал ответа на весь вопрос. Впрочем дам совет, хоть он и не будет воспринят сейчас: не надо напирать на хитрые маппинги, чем они прозрачнее, тем проще разработчику работать с базой. Этот факт все равно не скроешь, хоть 50 абстракций наверни сверху.

Чего конкретно не хватает в ответе?
За пределами сущностей пришлось переделать очень не много, и то скорее потому, что RepositoryХзЧто привелись к нормальному GenericRepository с использованием Specification, что дало возможность выгребать везде одинаково необходимое кол-во необходимых сущностей, включая вложенные, при необходимости.

Ну и не ясно что значит "не надо напирать на хитрые маппинги". Они могут быть продиктованы бизнесс-требованиями, имеющейся базой данных, которая уже есть такая какая есть и её нужно замапить.

Z>Очень и очень вложенной, обычная N+1 проблема навигационного доступа. В гибернейте, в моем случае, это выглядело бы как запрос к нужным сущностям, апдейт и сохранение. Именно таким запросам мешают различные репозитарии вкупе с запретом на IQueryable. В bltoolkit вообще, прямой апдейт в БД.

глупости. сделайте эту сущность Aggregation Root, и получите к ним доступ через репозиторий. не вижу проблем.

Z>Я рад, что развеял заблуждение:

нет, не развеяли. выносить IQueriable очень плохая практика, нарушающая инкапсуляцию. Expression можно юзать, но свобода остаётся. а чем больше свободы — там проще написать неправильный код.

Z>Когда получит тогда и надо вводить его. Сто процентов что, введенный сейчас он не ляжет на неожиданно возникшие вебсервисы органично, будут нюансы.

Паттерн Repository по сути является не чем иным, как реализацией массива в памяти с разными заморочками. Если он таким и будет оставатся, то в совокупности с UnitOfWork, привязывание его к веб-сервисам пройдёт прозрачно.