Отделение запросов EF от BL — методы расширения VS Class-Per-Query

Я прочитал десятки постов о плюсах и минусах попыток имитировать \ подделывать EF в бизнесе. логика. Я еще не решил, что делать, но знаю одно: мне нужно отделить запросы от бизнес-логики. В этом постея увидел, что Ладислав ответил, что есть 2 хороших способа:

1. Пусть они будут там, где они есть, и используйте настраиваемые методы расширения, представления запросов, сопоставленные представления базы данных или настраиваемые определяющие запросы для определения повторно используемых части.
2. Выставляйте каждый отдельный запрос как метод некоторого отдельного класса. Метод не должен выставлять IQueryable и не должен принимать Expression в качестве параметра = вся логика запроса должна быть заключена в метод. Но это сделает ваш класс охватывает связанные методы, очень похожие на репозиторий (единственный которые можно высмеять или подделать). Эта реализация близка к реализация, используемая с хранимыми процедурами.

1. Какой метод, по вашему мнению, лучше и почему?
2. Есть лиКАКИЕнедостатки в размещении запросов на своих местах? (возможно, потеря некоторых функций из EF или что-то в этом роде)

3. Должен ли я инкапсулировать даже самые простые запросы, такие как:

   с использованием (объекты MyDbContext = new MyDbContext)
   {
   Пользователь пользователь = сущности.Пользователи.Найти (идентификатор пользователя); // ИНКАПСУЛИРОВАТЬ ЭТО?
   
    // Здесь какой-то BL-код
   }