HttpContext vs HttpListenerContext

Question

Beim Portieren einer Webapp von IIS/asp.net zu HttpListener etwas schien mir eher seltsam.

Während beide ein Konzept von Kontext, Anforderung und Antwort haben, teilen die HttpListener-Varianten keine gemeinsame Schnittstelle mit den IIS/asp.net-Varianten, trotz der Tatsache, dass die Schnittstellen fast identisch sind.

Um dies zu umgehen, habe ich meine eigenen gemeinsamen Schnittstellen (IContext, IRequest und IResponse) erstellt und die entsprechenden servergenerierten Objekte mit Implementierungen dieser Schnittstellen umwickelt, so dass ich nicht zwei separate Implementierungen der Handler-Code, den ich portiere.

Dies hat zu einer Klassenexplosion von Wrappern (insgesamt 10) geführt, nur um diese fehlende gemeinsame Schnittstelle zu codieren.

Habe ich einen Trick verpasst, oder ist das nur ein Manko der .net-APIs?

Answer 1

Ich würde sagen, der ganze HttpContext hat diesen Mangel. Es ist die gleiche Situation, die beim Hinzufügen von Komponententests auftritt, wenn Sie diese umhüllen, um sie in den Komponententests durch Mocks ersetzen zu können.

Answer 2

Ich stieß auf die gleiche .NET-Design-Beschränkung beim Schreiben eines Handlers, der sowohl kompatibel mit IIS (IHttpAsyncHandler) als auch Standalone (HttpListener) sein musste. Ich habe den gleichen Ansatz gewählt, einen gemeinsamen Wrapper für beide zu schreiben. Es scheint in der Tat ein Manko der .NET APIs zu sein.