Skip to content

I suggest you ...

← Feature Requests

Refactor to use HttpRequestBase and HttpResponseBase

Much of the existing code implements IHttpRequest and IHttpResponse interfaces and writes complete code for implementing these. That was necessary before the redesign in 4.5 implemented mockable versions of the non-inheritable old HttpResponse classes.

I think it can reduce the amount of code in SS and enable use to not need to use global items like HttpContext.Current.Request which results in - non-testable controllers.

The change to help the above situation I implemented grew out of scope, but thought it worthwhile to explore for a later version.

https://groups.google.com/forum/#!searchin/servicestack/httpcontextbase/servicestack/fpr-QlOH-dY/PFtbLXaW-IQJ

1 vote
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Wayne Brantley shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Wayne Brantley commented  ·   ·  Report

    Demis,
    I was not suggesting to force coupling to concrete implementions. Rather I was saying that your current implemention is already 95% equal to the existing concrete implementation! You would keep your interface, just the now 'standard - non iis specific' classes included in .net are what you already need.

    Please take a look at them, I think you will see what I am talking about. If you still do not agree, please can I have a way to get rid of the evil need to use the unmockable global "HttpContext.Current.ToRequestContext()" and let me use the this.HttpContext (which is now based off of the HttpRequestBase and are now easily mockable, etc).

  • AdminDemis J Bellot (Developer, ServiceStack) commented  ·   ·  Report

    I don't believe so, forcing coupling to concrete implementations is evil. it inhibits its ability to be Mocked and substituted and given the definition is outside of our control we would've lost the freedom to add our own high-level properties as we do with OperationName and ResponseContentType.

    If you need to support multiple host implementations, binding to interfaces and having complete freedom in the implementation is the best way to do this - it definitely hasn't been a burden.

  • Wayne Brantley commented  ·   ·  Report

    This really would help in testing, because as it is now I need to use the global item. Additionally what I meant around 'reduce the amount of code' is - if the HttpRequestBase and HttpResponseBase had existed when you started, I believe you would have been able to just inherit from those classes instead to implement most all of your interface.

  • AdminDemis J Bellot (Developer, ServiceStack) commented  ·   ·  Report

    There's definitely not a lot of code we just have 1 simple wrapper for each which are still required to encapsulate the differences between ASP.NET / HttpListener / MQ / future Hosts and nuances across the different platform.

    Can you also list use-cases or end-user benefits with feature requests, thx.

Feature Requests

Categories

Feedback and Knowledge Base

(thinking…)