在数据访问层访问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.

推荐答案

没有访问HttpContext Web应用程序是不好的做法，因为它将您的代码与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容器构建整个对象hiearchy。

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屋！