HttpContext против HttpListenerContext

Question

При переносе веб-приложения из IIS / asp.net в HttpListener что-то показалось мне довольно странным.

Хотя оба имеют концепцию контекста, запроса и ответа, варианты HttpListener не имеют общего интерфейса с вариантами IIS / asp.net, несмотря на то, что интерфейсы почти идентичны.

Чтобы обойти это, я создал свои собственные общие интерфейсы (IContext, IRequest и IResponse) и обернул соответствующие объекты, генерируемые сервером, реализациями этих интерфейсов, так что мне не нужны две отдельные реализации обработчика код, который я портирую.

Это привело к взрыву класса оболочек (всего 10), просто для кодирования этого отсутствующего общего интерфейса.

Я пропустил хитрость или это просто недостаток .net API?

Answer 1

Я столкнулся с тем же ограничением дизайна .NET при написании обработчика, который должен был быть совместим с IIS (IHttpAsyncHandler) и автономным (HttpListener). Я применил один и тот же подход к написанию общей оболочки для обоих. Кажется, это действительно недостаток API .NET.

Answer 2

Я бы сказал, что весь HttpContext имеет этот недостаток. Это та же самая ситуация, которая возникает при добавлении модульных тестов, вы упаковываете их, чтобы их можно было заменить на макеты в модульных тестах.