访问HttpContext.Current在数据访问层 [英] Accessing HttpContext.Current in Data Access Layer
问题描述
根据
我来这个实体方面应该被视为一个单位的工作，因此不重用的结论。所以我想在我的资料库，以prevent性能/线程（联合国）的安全问题，以每创建一个HttpContext的obejctcontext。我想在库定义的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应用程序的外面是不好的做法，因为它紧密结合您的code到网络环境。可能是你正在寻找与每个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寿命允许每次调用单个请求中解决返回同一个实例。
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.
您可以去甚至让使用您的企业服务的容器解决该类进一步的。它通常以<一做href=\"http://consultingblogs.emc.com/matthall/archive/2009/03/25/asp-net-mvc-with-castle-windsor.aspx\"相对=nofollow> 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统一，但它不按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屋！
