HttpContext vs HttpListenerContext

问题:

While porting a webapp from IIS/asp.net to HttpListener something struck me as rather strange.

While both have a concept of Context, Request and Response, the HttpListener variants share no common interface with the IIS/asp.net variants, despite the fact that the interfaces are almost identical.

In order to work around this, I have created my own common interfaces (IContext,IRequest and IResponse) and wrapped the corresponding server generated objects with implementations of these interfaces, so that I don't need two separate implementations of the handler code that I am porting.

This has resulted in a class explosion of wrappers (10 in all), just to code around this missing common interface.

Have I missed a trick, or is this just a shortcoming of the .net APIs?

回答1:

I would say the whole HttpContext has this shortcoming. It is the same situation that happens when adding unit tests, you wrap those to be able to replace with mocks in the unit tests.

回答2:

I ran into the same .NET design limitation when writing a handler that needed to both be compatible with IIS (IHttpAsyncHandler) and stand-alone (HttpListener). I took the same approach of writing a common wrapper for both. It seems to be a shortcoming of the .NET APIs indeed.