HttpContext против HttpListenerContext

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

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

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

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

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


http .net iis
person spender    schedule 10.03.2009    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

person eglasius    schedule 10.03.2009

arrow_upward
4
arrow_downward

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

person David Burg    schedule 19.10.2011