A Look at ASP.NET 5: Part 4 - MVC 6

I had planned on finishing these a long time ago, but working on my Pluralsight course about ASP.NET 5 distracted me. Sorry about that.

If you’ve been doing web development in .NET, you probably have at least a passing experience with ASP.NET’s MVC framework. At it’s core, it’s a common way to build and architect web applications. The new stack is built on the same metaphors from the older versions. If you’ve been using MVC before, you won’t be lost and some of the additions are welcome.

I’ll explain what I’m doing in a series of blog posts and link them all here as I write them. The plan is to write posts about:

In this post I’m going to make an assumption you’ve used MVC before. Because of that, I’m not going to cover the why as much as the how and compare it to the earlier versions.

Configuring MVC

Out of the box with a new project, MVC get’s configured for you but let’s look at what that means and why you’d care.

In the ConfigureServices method (inside startup.cs), MVC is added to the service container using the innocuous AddMvc method:

// Add MVC services to the services container.
services.AddMvc();

This call, like much of what is in the ConfigureServices method is just about registering the service classes. But to actually support MVC, we need to go to the Configure method of the startup.cs and use the MVC functionality:

It may seem odd to have to add it in both places, but again remember that ConfigureServices is about configuring the services, and Configure is about adding middleware to the pipeline. In fact the order is important in Configure:

The order of these middleware calls are important as if MVC is called before Identity is called, then authorization is never reached. Though not a hard and fast rule, the last piece of middleware I’m using is usually the UseMvc call. You can see that you can configure routes directly in the UseMvc method like you’ve probably done in previous versions of MVC.

Controllers

Also like previous versions of MVC, a typical controller simply derives from the Controller class:

public class HomeController : Controller

Depending on how you were using dependency injection in your older MVC projects, it’s built into the platform now so you can inject services you need directly into the controller constructors:

Action methods in controllers are largely unchanged except they should be returning a IActionResult instead of an ActionResult (though both are supported). The IActionResult is a little cleaner and will be performed asynchronously:

In the current version of the tooling (at least on my machine), all the “Create View” and “Go to View” integration seems to be missing, but that was just a shortcut anyway.

Views and Razor

Views are also pretty similar to what you used in prior versions. Razor is still the language of choice and most of the typical Razor syntax is support with some nice additions. But for most cases, the Razor you’re used to will just work. For example:

One thing that you can see in the new MVC is that they want to encourage more HTML-like decorators instead of having to use @Foo style razor as much. This is most starkly obvious with tag helpers. But before I show you them, let’s talk about a new file that can exist in the view folder:

The _ViewImports.cshtml file is where you can import assemblies and namespaces into all your views. This is the alternative to the old web.config method. By default, this file is how they’re adding tag helpers into the views, but it’s good to see what it looks like:

This is bringing in the three namespaces to all the views as well as adding the default tag helpers to each view. But what are tag helpers?

Tag Helpers

Like I mentioned, the team is trying to move to allow more HTML-attribute-like syntax if you want to use it. Tag Helpers are a more readable version of functionality like form input control, action links and the like. But your old style syntax for ActionLinks and Forms still work:

Note the different tag helpers allow us to specify the generation of the different input types without having to hack together the other attributes we need (e.g. class and placeholder). In this example you can see a number of these that are important:

asp-for: Used to specify properties are mapped the @model of the page. Works for labels and form contols.

asp-validation-for: Used to specify the text of the validation for a property of the @model

asp-validation-summary: Used to show the validation summary (for the model or the model and properties).

There are a number of other tag helpers that you can use but hopefully you can see the power of them on display here. I like this new model as it allows most of the pure-HTML approach to be used and just decorate it with the MVC helpers as necessary. It’s not as jarring to read either, though some will argue that it’s hard to see what is client-vs-server code here.

Whether you use tag-helpers or not is more a matter of style than rule, but I, personally, like them.

Next time, I’ll use the MVC 6 framework to expose an API and say goodbye to Web API reluctantly.