Introduction to ASP.NET Core part 28: summary

Introduction

In the previous post we looked at how to log out from the model .NET Core web application. We also saw how to add a simple section with the user’s login state and the appropriate login/logout/register buttons. This was also the last post in this introductory series.

In this post we’ll just summarise what we’ve learnt.

This series was sort of a bit-of-everything introduction of .NET Core. So what’s .NET Core again? It is a new cross platform modular framework for web applications similar to ASP.NET. However, it has a number of features that are markedly different from traditional ASP.NET. It is still in preview mode at the time of writing this post but it’s good to get familiar with those new features as early as possible. .NET Core is meant to be the future direction of .NET development. There’s a number of significant changes compared to the earlier versions of ASP.NET that .NET developers will need to get used to.

.NET Core marks a significant shift from Microsoft’s past policies and attitude of targeting Windows only and keeping as much as possible secret and paid. .NET Core is cross-platform and designed to run on multiple operating systems: Windows, Mac OS and Linux. It is also open-source.

Another important change is the level of modularity of .NET Core projects. With .NET Core we are free to import those libraries and dependencies that are used in our project. .NET Core is lean and we don’t have to drag along all the services offered by .NET that we might not even need.

We’ve gone through a number of topics in this series including the following:

• The new project structure: there’s a brand new project structure in .NET Core compared to previous versions of ASP.NET projects. Global.asax is gone and web.config has a dramatically reduced role. They have been replaced by Startup.cs, appsettings.json, project.json and also global.json to some extent. Startup.cs is the new Global.asax.cs. It’s been around for a while but it coexisted with Global.asax and Global.asax was still THE startup file. In .NET Core Startup.cs is supposed to take care of all startup tasks where various things such as dependencies and middleware are registered. appsettings.json is the new JSON based settings file. In the old web.config file we stored our application settings and connection strings in the appSettings and connectionStrings sections. appsettings.json holds these values in a lot more flexible way where the settings can be stored in a JSON object with all its flexibility. project.json mainly holds the dependencies of the web project. It also shows a number of other options such as the supported runtimes and frameworks. By default the “src” folder holds the items that should be included in the compiled project. The wwwroot sub-folder is supposed to include the static files of the application: scripts, stylesheets, images and static HTML pages. So there’s a lot of new stuff to digest here for someone just starting off with .NET Core.
• Dependency injection: Startup.cs offers a brand new way of registering the dependencies that our controllers and other objects may need. We can tell the application which concrete implementation of a required abstract dependency to inject at runtime. Startup.cs is also the place where we install new middleware in the component pipeline and declare that we want to use MVC, an identity manager and a database context.
• Middleware and the component pipeline: this is not entirely new since the component pipeline was introduced with OWIN and Katana in MVC 5. An incoming HTTP call will go through the registered middleware components in the order that they were registered in Startup.cs. in the Configure method. By convention a component can be installed using an extension method on the IApplicationBuilder interface whose name starts with “Use”, “Run” or “Map” such as UseLoggerComponent or UseFileServer. We can construct and register our own components and we’ve seen some examples of doing that.
• Environments and settings: a web application can run in various environments such as Dev, Alpha, Production, Release etc. This depends on what policy and naming convention a company is following. .NET Core has a couple of built-in environment names. It’s also easy to create a new environment name and tweak the behaviour of the application based on that value. E.g. the connection string and various app settings will most certainly differ from environment to environment. Due to the new app settings structure in appsettings.properties we can better describe the various settings in JSON objects rather than inflexible key-value XML elements.
• MVC: the basic implementation of MVC in .NET Core is largely the same compared to ASP.NET MVC. We still have controllers, views and models in the well-known folders like Controllers and Views. Controllers have action methods that return a view. We also still have partial views, data annotation of view models and the _ViewStart file which is mainly used to register a common layout view. One of the significant novelties is the tag helper library. Tag helpers are an alternative way of authoring views. If you don’t like mixing C# with HTML which is a characteristic of Razor views then the tag library offers an elegant alternative. Tag helpers are converted into “proper” HTML tags on the server side, so it’s a server side technology that doesn’t require any special javascript for rendering. We looked at a couple of built-in tags that come with .NET Core. We also saw how to build our own tags. Another interesting addition is the view component. A view component is a great alternative to partial views. It has a structure similar to MVC with its own naming conventions, views and dependencies. View components are used within other views and are a lot more flexible than partial views. Another addition in .NET Core is the _ViewImports view file. Its main role is to register the tag helper libraries and common namespaces for our views. If there’s a namespace which is used throughout multiple views then it can be registered in a _ViewImports file so that the namespace will be registered in the views that “derive” from it. We can also mention the option of dependency injection in views using the inject directive as a new feature. Using that directive we can inject dependencies to views directly without the need to extend the view model that’s passed into the view. However, use this feature sparingly. Views are not supposed to be “clever” i.e. they should be void of their own logic as much as possible.
• EntityFramework: EF is of course still alive and kicking and comes with its own .NET Core version to be used with .NET Core projects. We didn’t go too deep here since EF deserves its own series as it is a large topic. We only saw how to start with code-first and migrations so that we created a simple database based on our model. Otherwise LINQ to Entities with a DB context is much as the same as before.
• User management: user management has two distinct facets. We can talk about users registered in the database and users that are currently logged into the application. .NET Core offers built-in but extensible classes for both session handling and user persistence. Long gone are the days of rigid role and membership providers. The built-in objects such as User, UserManager and SignInManager all offer a good starting point for user management in the application so that you can concentrate on building the true business value of the application.

We’ve only scratched the surface of what .NET Core has to offer. I hope that it was enough to get your interested at least so that you can explore each topic further.

View the list of MVC and Web API related posts here.