Core MVC follows the trend from Microsoft of keeping everything off unless you intentionally opt in. Core MVC applications are simply console applications, and everything from the webserver to how the application responds to HTTP requests must be configured. This video covers the Startup.cs class and migration of filters, routing, and authentication.
- [Narrator] In Core MVC applications, the Startup.cs class defined by the WebHostBuilder configures the vast majority of what was done in many places in MVC 5. Pulls any configuration data through appsettings.json. You saw that in an earlier module. It configures all the services used by the application including populating the dependency injection container, and it configures the HTTP pipeline.
So, when we talk about migrating the Global.asax, Startup.cs, and App_Start from MVC 5, we're really talking about four different things. Bundling and minification, and we've already handled that with the BundlerMinifier, filters, and the filter that we are using in the MVC 5 app is the HandleErrorAttribute, Routing, and Authentication. All these different items are replaced by calls in the Startup.cs file.
So back in the Core MVC movie application in the Startup.cs file we've already talked about the configuration builder and how it uses the appsettings and the application environment to pull in any application-specific configuration data. The next method is to configure services and this is where we add items into the dependency injection container. And we'll see this in a later module. The configure method replaces the vast majority of the configuration done in all those different locations in MVC 5.
You start off by adding a longer factory and right now we're just using Console and dBug. And then we check to see if the environment is development. If it is, we use the developer exception page, which takes the place of the dBug Custom Errors section of the Web.config. And that shit's a lot more robust than what you get in MVC 5. If we're not in development, we'll use the exception handler, and redirect the user to the error view on the home controller.
Just like everything else in .NET Core, Core MVC is an opt-in. If we want to have static files render, we need to opt-in by saying Use Static Files. The final section of the configure method defines our routing table. So if we had more complex routes in our MVC 5 app we would place them here. Now we don't have to add in the ignore route for the HTTP handler that was in the MVC 5 version, because HTTP handlers don't really apply in .NET Core.
Phil Japikse begins by showing how to install and update the .NET Core SDK. He reviews the functionality of the MVC 5 app, explains how to create necessary projects, and discusses migrating static content. Next, he demonstrates how to create a data access layer, complete the server-side migration, set up the HTTP pipeline, add custom items into the dependency injection container, leverage the new project configuration system, and migrate the controllers. Phil then introduces Tag Helpers—one the big new features in ASP.NET Core—and uses them to migrate and simplify the views. Phil also demonstrates how to create and use custom Tag Helpers. To wrap up, he covers working with view components, explaining what they are and why they're helpful. He walks through how to create the server-side view component code, and how to refactor your app and invoke the view component.
- Reviewing the MVC 5 application
- Creating the data access layer
- Adding and updating the models
- Updating the database
- Completing the server-side migration
- Configuring the HTTP pipeline
- Configuring and using dependency injection
- Migrating the views
- Creating view components