This project has moved and is read-only. For the latest updates, please go here.

Katana Owin wrapper classes

Jul 1, 2014 at 3:43 PM
Regarding:

http://whereslou.com/2014/06/10/asp-net-vnext-moving-parts-owin/

"Another point of feedback was that the various wrapper classes like OwinMiddleware, OwinRequest, and OwinResponse can cause confusion because the OWIN specification itself is type-less."

While the motivation behind keeping the spec type-less is clear, the implementation should also consider productivity motivations for the common-scenarios. It is by far less error prone, more concise (no casts) and self-documenting (intellisense) to use a typed interface in this context.

Please retain such wrapper classes in future Katana releases at least for mature environments like Http, where the spec is fairly stable and well understood (e.g HttpOwinMiddleware, HttpOwinRequest…)

Furthermore, designating these as “helpers” rather than wrappers should clarify any possible confusion for people building feature-rich frameworks.

Regards,

-Itai
Jul 1, 2014 at 5:19 PM
The helpers will certainly continue to exist since they are what make the implementation usable. We primarily want to separate out the naming and concepts to distinguish between the spec and the implementations.

Here's what we've done for vNext so far:
https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.AspNet.Http/HttpContext.cs
https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.AspNet.Owin/OwinEnvironment.cs
https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.AspNet.Owin/OwinFeatureCollection.cs
Jul 1, 2014 at 5:52 PM
So what impact (if any) will these future changes have on existing middleware code such as:

public class MyOwinMiddleware : OwinMiddleware
{
public MyOwinMiddleware(OwinMiddleware next) : base(next)
{            
}

public override async Task Invoke(IOwinContext context)
{
    context.Response.StatusCode = 200;
}
}
Jul 1, 2014 at 6:00 PM
Two options:
  1. Microsoft.Owin is a micro-framework on top of OWIN, and as such the Microsoft.AspNet.Owin adapters can be used to iterop with it.
  2. Middleware using Microsoft.Owin can be easily migrated to use Microsoft.AspNet.Http. e.g. IOwinContext -> HttpContext, but most of the properties and methods remain the same.
Jul 1, 2014 at 6:14 PM
So a migration (#2) would be this ?

public class MyOwinEnvironment : OwinEnvironment
{
public MyOwinEnvironment(OwinEnvironment next) : base(next)
{            
}

public override async Task Invoke(HttpContext context)
{
    context.Response.StatusCode = 200;
}
}
Jul 1, 2014 at 6:18 PM
More like:
public class MyMiddleware
{ 
 private RequestDelegate next;
 public MyMiddleware(RequestDelegate next)
 {
  this.next = next;            
 }

 public override async Task Invoke(HttpContext context)
 {
  context.Response.StatusCode = 200;
 }
}
Jul 1, 2014 at 6:26 PM
Ok.. I just liked where the existing interface is setup to implicitly call the next middleware without me having to be concerned about it in my Invoke code.. not a big deal but nevertheless, one more thing to re-remember ;)
Jul 1, 2014 at 6:30 PM
Ummm, that's not how that worked... OwinMiddleware never implicitly called next for you, it just stored next in a variable in the base class. You still have to call next in your Invoke method (if you're not generating the response locally).
Jul 1, 2014 at 6:31 PM
    public abstract class OwinMiddleware
    {
        protected OwinMiddleware(OwinMiddleware next)
        {
            Next = next;
        }

        protected OwinMiddleware Next { get; set; }

        public abstract Task Invoke(IOwinContext context);
    }
Jul 1, 2014 at 6:40 PM
Oops, your right.. double checked it indeed I'm calling await Next.Invoke(context).

10x