在数据访问层访问 HttpContext.Current [英] Accessing HttpContext.Current in Data Access Layer

问题描述

基于对我在 分层架构中的实体框架的问题给出的答案，现在我想移动我的存储库(现在只负责 CRUD 抽象，而不是业务逻辑的东西)到 DAL 并为业务逻辑保留 BLL.
我得出的结论是，实体上下文应该被视为一个工作单元，因此不能重用.所以我想在我的存储库中为每个 HttpContext 创建一个 obejctcontext 以防止性能/线程 [un] 安全问题.我想在存储库中定义 objectcontext 如下:

Based on the given answer to my question at Entity Framework in layered architecture, Now I'd like to move my repositories (Which are now only responsible for CRUD abstraction, not business logic stuff) to DAL and reserve BLL for Business Logic.
I've come to the conclusion that the entity context should be considered a unit-of-work and therefore not reused. So I'd like to create an obejctcontext per HttpContext in my repositories to prevent performance/thread [un]safety issues. I'd like to define the objectcontext in repositories as follows:

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 变量.我不确定这是否是一个好的做法，想知道您的意见.

In that case, the DAL project should be aware of HttpContext.Current variable. I'm not sure if this is a good practice and would like to know your opinions.

推荐答案

不在 Web 应用程序之外访问 HttpContext 是不好的做法，因为它会将您的代码与 Web 环境紧密耦合.您正在寻找的可能是具有每个 HTTP 请求对象生命周期管理器的控制容器反转.

No accessing HttpContext outside of the web application is bad practice because it tightly couples your code to web environment. What you are looking for is probably inversion of control container with per HTTP request object lifetime manager.

假设您将业务逻辑定义为:

Suppose that you define your business logic as:

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

  ...
}

现在，当您想要使用 BusinessService 时，您必须创建它的实例并将其作为参数传递给 IObjectContext.使用控制容器反转时，您可以利用此定义而不是构造函数调用，例如:

Now when you want to use BusinessService you have to create its instance and pass it IObjectContext as parameter. When using inversion of control container you can take advantage of this definition and instead of constructor call something like:

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

控制反转 (IoC) 容器必须配置为能够实例化 IBusinessService 和 IObjectContext 的具体实现.此外，这种配置通常允许定义实例化对象的生命周期.当每个 HTTP 生命周期被允许时，在单个请求中对 Resolve 的每次调用都会返回相同的实例.

Inversion of control (IoC) container has to be configured to be able to instantiate concrete implementation of IBusinessService and IObjectContext. Moreover this configuration usually allows defining lifetime of instantiated object. When per HTTP lifetime is allowed each call to Resolve within single request returns same instance.

通过让容器使用您的业务服务解析类，您可以走得更远.通常使用 ASP.NET MVC.在这种情况下，您只需在主类(控制器)中将接收服务的构造函数定义为参数，并让 IoC 容器构建整个对象层次结构.

You can go even futher by letting container resolve the class using your business services. It is usually done with ASP.NET MVC. In such case you only define constructors receiving services as parameters in your main classes (controllers) and let IoC container to build whole object hiearchy.

对于控制容器的反转，请检查例如温莎城堡.我正在使用 MS Unity，但它没有提供开箱即用的每个 HTTP 生命周期管理器.

For inversion of control containers check for example Windsor Castle. I'm using MS Unity but it doesn't provide per HTTP lifetime manager out of the box.

这篇关于在数据访问层访问 HttpContext.Current的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！