Кстати, я так понимаю, что тогда этот контекст надо создавать в методе контроллера, который вызывается пользователем, и затем передавать УЖЕ СОЗДАННЫЙ В КОНТРОЛЛЕРЕ контекст в модели (и дальше по иерархии моделей)? Да?

авторчто это? z => z.x == c.x
и прочее подобное.
Это и вообще почти все нагромождения в моём коде - чтобы просто показать, что я там что-то делаю, как-то выбираю данные и прочее. Основной вопрос - чего делать с контекстом БД в случае, когда много конструкторов одиз из другого вызываются.

авторОстается только добавить, что если приложение не сложное, то все это лишняя головная боль
Во-во. Если я напишу репозиторий и выложу свою поделку сюда, набегут критики, которые будут говорить, что конкуренции не обработаны, что нет защиты от дурака, что не предусмотрено аварийное отключение электроэнергии и пр. Уже обсуждали недавно в одной теме, где человек тоже про репозиторий спрашивал. Вроде, пришли в основном ко мнению, что либо делать хорошо, реализуя вот все эти хреновины с конкуренциями и пр., либо пользоваться ORM от EF как репозиторием напрямую.

автортяжелая инициализация в конструкторе, гораздо прагматичней инициализация по требованию
А, понял. Т. е. мне надо убрать все эти ToList() и просто пройтись тем же foreach'ем по IEnumerable (или IQuerable) в предсталении. Тогда непосредственно запрос из БД будет только на этапе создания представления, так?

авторВот только ТС что-то там развивать собрался и при подходе "а репозиторий мне пока не нужен и производительность мне не важна сейчас" велика вероятность наступить не на одни грабли.
Приложение, скорее всего, будут развивать. Только здесь и сейчас просят в сжатые сроки, в которые я им нормальный репозиторий не выдам. Значит, будут переписывать потом нормально.

Где-то в степиГде-то в степи,
конечно об этом говрить можно много, но с моей точки зрения, нужно поработать с базой, или денормализовать ее, накинуть связи
там в общем то тремя запросами не пахнет, там куда больше
Я тут подумал. Наверное, джойнами можно будет. БД нормальная, и связей там может даже больше, чем надо. Просто я с джойнами не очень дружу. Мне проще три простых запроса и потом из их результатов создать сложную модель. Ну, я посмотрю, что там у меня можно с джойнами сделать. Ещё раз говорю, что код, что я написал - от балды, лишь бы показать, что конструкторы не пустые и что-то делают.

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

Приложение, скорее всего, будут развивать. Только здесь и сейчас просят в сжатые сроки, в которые я им нормальный репозиторий не выдам. Значит, будут переписывать потом нормально.Вы только предупредите о такой вероятности тех, кто просит, чтобы они потом не удивлялись, что новые требования вызывают следующую реакцию: "Чёрт, это надо всё переписывать".
На этом всё серьёзное мировое ПО стоит. Я тут даже боюсь соваться со своими нововведениями. Лучше сделаю как все, пока сам крутым не стал и не получил значимость и мировую известность. Потом создам свой шаблон проектирования. Какой-нибудь "со мной переписывать некогда не надо".

Где-то в степиuser7320,
не нравится
1 тяжелая инициализация в конструкторе , гораздо прагматичней инициализация по требованию
2 куча запросов бомбит сервер имхо не осмысленно.
проще сделать наследование c:ZZ и вытащить все одним джойном,( ну тут надо смотреть структуру)
3 не желание применять фабрику и инжекции
Да и вообще все не нравится вплоть до названий полей и классов
Я уже понял, что вы имели ввиду. Уже сделал проще. Типа такого . Там строка

ur => new UseRecommendationModel()

и далее данные передаются там. А в UseRecommendationModel свой подзапрос может быть. В результате всё в пределах одного запроса и контекст БД никуда в конструкторы не передаётся.