ASP.NET MVC 6 supports both regular controllers (inheriting from Controller base type) and POCO controllers. Let’s have a look at how the discovery of them happens in ASP.NET MVC 6. Note that the code and mechanisms discussed in this article were introduced after ASP.NET 5 beta3 was released, so it is not yet available if you use the version of ASP.NET 5 bundled with Visual Studio 2015 CTP6.
This is something I hacked together last night, but it was a very interesting exercise into customizing the new (or rather, future) ASP.NET MVC 6 to suit your needs.
If you visit this blog from time to time, some time ago I blogged about building strongly typed routing provider for ASP.NET Web API (code is here). That was built around extensibility points provided by the direct routing mechanism (better known as direct routing’s default implementation – attribute routing).
So I thought, it would be fun to port this solution to MVC 6. However, while MVC 6 supports attribute routing, it does not provide the same abstractions over the routing mechanism. Instead it exposes something new for both MVC and Web API developers – IApplicationModelConvention, which is what we’ll use here.
There are many posts out there, including on this blog, about what’s in ASP.NET MVC 6 and how to use it. This one however, will be about what’s not in the framework, or at least not in the same way as you might be used to it from MVC 5/Web API 2 – the ability to override filters. I was recently working on an MVC 6 project and ran into this exact problem.
In MVC 5 and Web API 2, there was a built in way to do it, and even though it was not very extensible, it proved to be very handy (at least for me).
IN MVC 6, these override filters are gone, so at first glance, filter overriding is quite difficult. In reality, that’s not the case, you just need to know what to do – let’s have a look.
Migrating an MVC 5 project to ASP.NET 5 and MVC 6 is a big challenge given that both of the latter are complete rewrites of their predecessors. As a result, even if on the surface things seem similar (we have controllers, filters, actions etc), as you go deeper under the hood you realize that most, if not all, of your pipeline customizations will be incompatible with the new framework.
This pain is even more amplified if you try to migrate Web API 2 project to MVC 6 – because Web API had a bunch of its own unique concepts and specialized classes, all of which only complicate the migration attempts.
ASP.NET team provides an extra convention set on top of MVC 6, called “Web API Compatibility Shim”, which can be enabled make the process of migration from Web API 2 a bit easier. Let’s explore what’s in there.
When working with attribute routing in Web API 2 or MVC 5 it was relatively easy to get the route to the controller and the controller name out of sync. That was because the route always had to be specified as a string, so whenever you changed the name of the controller you would always have to change the string in the route attribute too.
That could be easily forgotten – especially if you use refactoring tools of Visual Studio or an external refactoring plugin.
This issue has been addressed in MVC6 with a tiny addition – the introduction of [controller] ad [action] tokens into attribute routing.
One of the key concepts in HTTP API development is the notion of content negotiation (conneg). ASP.NET Web API provided first class support for content negotiation through the use of MediaTypeFormatters.
While MVC 6 is a de facto brand new framework, rebuilt from scratch, the majority of concepts from MVC 5 and Web API 2 have naturally been brought forward, and conneg done through formatters are one of them.
Let’s have a look at formatters in MVC6.
One of the very cool features of the vNext of ASP.NET MVC (a unified framework set to succeed MVC, Web API and Web Pages) is the ability use POCO classes as controllers. No base class, no interface to implement, 100% convention.
Let’s look a little bit into that.
First the disclaimer. Yes, there are a lot of problems with using session in your ASP.NET applications. Moreover, by default, HTTP (and by extension, REST) is stateless – and as a result each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP.
So if you are designing a proper API, if you are a REST purist, or if you are Darrel Miller, you definitely do not want to continue reading this article. But if not, and you find yourself in a scenario requiring session – perhaps you are using Web API to facilitate your JS or MVC application, and you want to sync the state of Web API with the state of MVC easily, or you simply want a quick and easy way to persist state on the server side – this article is for you.
More after the jump.
OData support in Web API is arguably one of its hottest features. However, it’s support in Web API has been a bumpy ride – initially, OData was supported in a limited way only, and ultimately ended up being yanked altogether from the Web API RTM. It is however stil lpossible to use OData with Web API, only in a slighly different form , as an external NuGet package, which, in its pre-release alpha format was published last Wednesday, along the Web API RTM release.
This package is called Microsoft ASP.NET Web API OData and is a joint effort by Microsoft’s Web API and OData teams. Alex James has written a great introduction to the package, so I recommend reading it.
In the meantime, let me show you how to add $inlinecount support as for the time being, it’s still not provided there out of the box.
If you have been following this blog for a while now (and if not, I really hope you will!), you’d know that I am a big fan of Web API. I have been blogging a lot about Web API, through its beta, RC stages and even about features that were only available through the Codeplex builds and I have to say that it is a terrific bridge between CLR and HTTP and fits really nicely into the existing landspace of web technologies.
With that said, today is a really big and important day, as Web API has been publicly released in its RTM version. This effectively means that you have binaries you can safely use in production scenarios and take advantage of all the great features of the framework. You can download MVC4 (including Web API) RTM here.
Let’s go through the new features in RTM.