ASP.NET Abstractions: add HttpContextBase.Current

ASP.NET Abstractions: add HttpContextBase.Current by AtsushiEno

Closed

as By Design Help for as By Design

Type:	Suggestion
ID:	376426
Opened:	10/19/2008 3:25:12 AM
Access Restriction:	Public

Workaround(s)

view

There should be some replacement for HttpContext.Current in ASP.NET abstractions layer.

Details (expand)

English

.NET Framework 3.5 Service Pack 1

Windows XP Professional

Japanese

Currently any modern ASP.NET apps that are based on Abstractions layer still have to resort to HttpContext.Current to create HttpContextBase instance.

A good example is DynamicData which is the only present application of Abstractions. It internally depends on HttpContext.Current and hence it cannot be tested outside ASP.NET runtime.

(I'm unsure if ASP.NET MVC makes use of it; it uses different abstractions/routing assembly than .NET 3.5 SP1).

Providing HttpContextBase.Current which works almost similar to HttpContext.Current would solve couple of difficult situations to solve this kind of problem.

Or applications such as DynamicData should (have) expose(d) public HttpContextBase setter that is internally used by the framework.

Hi there! Thanks for the suggestion. This is by design.

Suppose HttpContextBase.Current existed.

To logically mimic HttpContext.Current, the property would have to be static. If the property is static you couldn’t mock it anyway! Even if it’s settable that is unacceptable to unit tests since you never want to use statics (they are global and affect global state). Unit tests should not affect global state in such a way as that could affect other unit tests. Unit tests need to be isolated and independent.

If something in Dynamic Data isn’t testable, it has nothing to do with System.Web.Abstractions, but probably something specific to Dynamic Data itself. I didn't actually see a specific problem in this bug report, but it might be worth reporting to the Dynamic Data team if you have something specific. For example, in MVC we always pass our contexts along and never use HttpContext.Current. If Dynamic Data did the same then that might solve the problem in their case.