ASP.NET 5: New HttpContext
ASP.NET MVC 6 is mostly about rework of framework internals and it comes with changes that affect also our applications. One important improvement is new HttpContext class. In this posting I will discuss about this new class a little bit.
Why new HttpContext?
New HttpContext was needed anyway because by default ASP.NET MVC 6 has no reference to System.Web assembly. All needed functionalities from this assembly are moved to new libraries and many of these are changed or will change (probably).
The other reason is too big object graph of current HttpContext. It takes approximately 30K in memory while new implementation takes around 2K. It’s a huge difference and it takes ASP.NET MVC more close to high-performance web frameworks. Plus ASP.NET MVC will be host agnostic – we can host it under different containers.
Speculation: Node.js Microsoft way?
To serve huge number of small API calls there is tool called Node.js. From Wikipedia article we can read:
Node.js applications are designed to maximize throughput and efficiency, using non-blocking I/O and asynchronous events. Node.js applications run single-threaded, although Node.js uses multiple threads for file and network events. Node.js is commonly used for real time applications due to its asynchronous nature, allowing applications to display information faster for users without the need for refreshing.
Although ASP.NET MVC is different – it’s asynchronous if needed. I just focus on aspect like huge throughput of small requests. I don’t think ASP.NET MVC will compete with node.js but at least it is possible to mimic something similar when thin framework is running under thin container and handles small requests.
Public interface of new HttpContext
New HttpContext has way smaller public interface than previous one (here I compare base contexts). Compared to old one with 36 public members the new one has only 23 public members.
The new HttpContext defines only the minimum needed for MVC applications. Some new methods maybe say you nothing and it’s not a problem – I will blog about new stuff in next posts. Now there’s one question – is this public interface really enough to save memory ~15x? Answer is no because down the way in object graph also some other objects are replaced by new ones that are more economic.
Conclusion
New ASP.NET MVC has many internal changes that make it independent of hosting container and leads us to even thinner and more performant web framework. Current applications may face some changes and moving to next version of ASP.NET MVC comes with changes to code for sure. What we achieve is better performance of our applications and possibility to run them almost everywhere we want.
HttpContext has been the death of me. I can’t wait for it to be taken out back and shot.
One of the most important questions is will they make every public member of HttpContext virtual? THEY BETTER.
It’s hard to predict if this happens. .NET framework’s founding ideas are coming from guys by strong practical background and they consider Java style all-members-virtual-by-default not very practical because all actions that class performs must be “user-proof” then. Also it hits performance because instead of making call to method CLR must traverse through virtual members table to find correct version of method to call.