МСУАлексей Кпропущено...
Зря. Сам же говорил, что чем больше слоёв - тем лучше. :-)
А смысл? Этот слой с легкостью покрывает универсальный репозиторий. Нафига мне IQueryable лохмотья? :)А действительно. Накой в базе "лохмотья" запросов в виде View/Inline UDF. Срочно убрать, всё должно делаться хранимыми процедурами, имеющими конкретный план выполнения. :-)

Тут тоже самое, IQueryable/Expression - это фрагменты запросов с возможностью их повторного использования. Согласен, гемора с ними больше, но при умелом их применении производительность вырастает в разы.

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

skyANAАлексей Кпропущено...
Чтобы избежать нежелательных распределённых транзакций и иметь возможность возвращать из методов IQueryable, временем жизни контекста лучше управлять через ThreadStatic + счётчик ссылок.
Сохранение static полей класса между запросами
ХреноРедькаНе гарантируется, что весь запрос от начала и до конца будет обрабатываться одним и тем же потоком.
Для хранения информации в контексте одного запроса надо использовать уже упомянутую здесь коллекцию HttpContext.Items.
[ThreadStatic]- неудачное решение в контексте ASP.NET.К чему тут эта ссылка? ХреноРедька оказался неправ. В том топике ниже опровержение этого утверждения.

skyANAСссылка полезна, т.к. там началось обсуждение ThreadStatic и HttpContext в ASP.Net.
По моему корреляция на лицо.А по-моему - нет. Какое имеет отношение к репозитариям моя реализация управления временем жизни EF-контекста?

skyANAтам началось обсуждениеОно там давно уже закончилось...

skyANAЯ не собираюсь с Вами дискутироватьВот и замечательно.