Доступ к HttpContext.Current в слое доступа к данным

Question

Основываясь на данном ответе на мой вопрос на Entity Framework in layered architecture, теперь я хотел бы переместить мои хранилища (которые теперь отвечают только за абстракцию CRUD, а не за бизнес-логику) до DAL и резерв BLL для бизнес-логики.
Я пришел к выводу, что контекст сущности следует считать единицей работы и, следовательно, не использоваться повторно. Поэтому я хотел бы создать obejctcontext для HttpContext в своих репозиториях, чтобы предотвратить проблемы с производительностью/потоком [un]. Я хотел бы определить ObjectContext в репозитории следующим образом:

public MyDBEntities ctx 
    { 
     get 
     { 
      string ocKey = "ctx_" + HttpContext.Current.GetHashCode().ToString("x"); 
      if (!HttpContext.Current.Items.Contains(ocKey)) 
       HttpContext.Current.Items.Add(ocKey, new MyDBEntities()); 
      return HttpContext.Current.Items[ocKey] as MyDBEntities ; 
     } 
    } 

В этом случае проект DAL должен знать о переменной HttpContext.Current. Я не уверен, что это хорошая практика и хотелось бы узнать ваше мнение.

Answer 1

Отсутствие доступа к HttpContext за пределами веб-приложения - это плохая практика, потому что он плотно соединяет ваш код с веб-средой. То, что вы ищете, вероятно, является инверсией контейнера управления с каждым менеджером жизненного цикла объекта HTTP.

Предположим, что вы определили свой бизнес-логику, как:

public class BusinessService : IBusinessService 
{ 
    // Constructor with dependency injection 
    public BusinessService(IObjectContext context) 
    { ... } 

    ... 
} 

Теперь, когда вы хотите использовать BusinessService вы должны создать свой экземпляр и передать его в качестве параметра IObjectContext. При использовании инверсии управления контейнера вы можете воспользоваться этим определением и вместо вызова конструктора что-то вроде:

IBusinessService service = container.Resolve<IBusinessService>(); 

Инверсия управления (IoC) контейнер должен быть сконфигурирован, чтобы иметь возможность создать экземпляр конкретную реализацию IBusinessService и IObjectContext , Более того, эта конфигурация обычно позволяет определить время жизни экземпляра объекта. Когда на каждый HTTP-ресурс разрешен каждый вызов Resolve в одном запросе возвращает тот же экземпляр.

Вы можете пойти еще дальше, разрешив контейнеру разрешить класс, используя ваши бизнес-услуги. Обычно это делается с ASP.NET MVC. В этом случае вы определяете только конструкторы, получающие сервисы в качестве параметров в ваших основных классах (контроллерах) и позволяя контейнеру IoC строить весь объект hiearchy.

Для инверсии контрольных контейнеров проверьте, например, Windsor Castle. Я использую MS Unity, но он не предоставляет администраторам на всю жизнь HTTP из коробки.