虽然从IIS / asp.net web应用程序来的HttpListener移植的东西让我觉得很奇怪。

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

虽然两者有语境，Request和Response一个概念，该变种的HttpListener共享与IIS / asp.net的变种没有统一的接口，尽管接口几乎是一样的。

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.

在为了解决这个问题，我已经创建了自己的公共接口（IContext，IRequest和IResponse），并包裹了相应的生成服务器对象使用这些接口的实现，使我不需要两个独立的处理程序的实现code，我移植。

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.

这导致了包装的爆炸级（10在所有），只是为了解决这个缺少通用接口code。

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

难道我错过了一次机会，或者是.NET的API这只是一个缺点？

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

推荐答案

我会说，整个的HttpContext有这个缺点。它是附加单元测试时，您缠绕那些能够替换在单元测试模拟，从而发生同样的情况。

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.