ASP.NET 5 isn’t released yet but most of the core technologies discussed here are released and usable today in .NET 4.0 up.
This series of posts is intended to be a practical look at these core technologies for the uninitiated, with focus on how most day to day ASP.NET applications will be written, this post will also serve as a jumping off point to find more detailed posts on specific subjects.
How ASP.NET v5 will most likely affect you, in a nutshell;
ASP.NET MVC, Web API and SignalR applications are going to be more efficient with ASP.NET v5, primarily because the System.Web assembly (ie. the whole ASP.NET stack) is not used. In fact with ASP.NET v5 and MVC6, you could host MVC applications without IIS.
It is also possible to write microservice middleware components that are extremely lean.
Web API: Lightweight framework for developing web services (this is built upon WCF).
vNext: The code name for ASP.NET v5 (including MVC 6)
Middleware: Components that can be written to run in the request pipeline. Common examples are logging and authentication components, but could include redirects, or Google Analytic page code injection for example. The point is that every request runs through these components, which will be small, reusable and also granular in developer ownership.
OWIN: An open web interface which describes how ASP.NET applications interface with IIS (and potentially other servers).
Katana: Microsoft’s implementation of OWIN; essentially it lets MVC, Web API, and SignalR run without the full ASP.NET stack, so it’s much more lightweight. Katana can be run on top of IIS or ‘self hosted’ without IIS.
Kestrel: An implementation of OWIN for Linux, so you can run your Web API applications on Linux. This isn’t some hack, but the whole point of OWIN’s creation.
If this is confusing, it might be because in the ASP.NET world we’re used to seeing ASP.NET and IIS as one monolithic beast, and aren’t used to seeing the server’s distinct parts (partly because they weren’t decoupled at all, in the past). The goal of OWIN is to decouple ASP.NET from IIS.
‘Middleware’ is one of those broad terms in computing that means different things to different people. In ASP.NET web development the term ‘middleware component’ means objects that are called for each request, in a sequence (pipeline), each having a turn to handle the request and response as needed. For example, an authentication component would typically be near the front of the queue for incoming requests, and validate the user before allowing the request to go further down the pipeline.
Articles on middleware tend to simplify their examples with ‘hello world’ type output, but in practice it is unlikely that you would output a complete (or even much of a) HTML page from a middleware component. That means that MVC Razor, or even Web Forms will probably still be doing the rendering work for you.
Further reading for the Middleware layer:
Middlware component examples from the world of Ruby (Rack), these are non .NET examples of the kind of functionality that can be built at the middleware level.
Excellent in-depth look at OWIN, Katana and Middleware, with examples.
At the top of the stack is your web application (likely MVC, AJAX SPA, Web Forms, or Static)
Further reading for the Application layer:
Latest posts by Jim Wright (see all)
- Remote debug .NET applications over the internet with Visual Studio - November 14, 2016
- Craft and elegance in programming - May 19, 2016
- Bluetooth Low Energy in Windows 10: Troubleshooting Capabilities - August 31, 2015