Forem: Patrick God

Blazor WebAssembly Full Stack Bootcamp

Patrick God — Thu, 15 Oct 2020 14:35:07 +0000

Introduction

Blazor WebAssembly is turning the web development world upside down.

With Blazor you can keep coding every part of your web application - meaning front end and back end - with the programming language and the framework you love - C# and .NET.

No need for JavaScript anymore and you can even use the same classes and methods you write for the server as well as for the client.

In this tutorial series, we will dive right into the code by first having a look at the standard example project of Blazor WebAssembly and then we already build the main project of this tutorial series, which is a classic online browser game, where users can create an army of fighters and send them into battle against other users.

Together with some customization options and climbing the leaderboard, this application will teach you how to use Blazor WebAssembly with Razor components in a playful way.

We will have a look at data binding and event handling, communication between components, forms with their built-in components and validation options, how to use views only authorized users can see, how to make calls to a web service, and much more.

Additionally, you will learn how to build the back end of the browser game with a Web API and Entity Framework to store all the data in a SQLite database.

By the end of this tutorial series, you will have what it takes to call yourself a full stack Blazor web developer.

With your new skills, you are ready to conquer any upcoming .NET web development project you want to build yourself or any project that is requested by a recruiter.

Are you ready? Let's start!

Tools

The only tools you need in the beginning are the .NET SDK and Visual Studio.

Depending on when you’re watching this course, you can choose to download the .NET Core 3.1 SDK, the preview or release candidate of .NET 5 - which will combine .NET Core with the older .NET framework, or .NET 5 has already been released, then you’re safe to choose this SDK.

This course will use .NET Core 3.1 because, by the time of writing these lines, this version has been the latest stable release. So to be absolutely safe, please choose this version as well - but there shouldn’t be many differences between .NET Core and .NET 5 if any.

Regarding Visual Studio, you can use the Community Edition of Visual Studio 2019. It’s totally free and provides all the functions we need. If you decide to use a preview version of a .NET SDK, you probably also need a preview of Visual Studio. Just keep that in mind. Otherwise, the latest released version of Visual Studio is perfect.

If you already want to get the necessary tools for the back end, you can download and install Postman, which we will use to test our web service calls later on. Sometimes it’s just nice to test a call to the Web API before you build the corresponding front end.

Additionally, you could already download the DB Browser for SQLite, which enables you to, well, browse through a SQLite database.

But, again, these tools are used later in this tutorial series.

For now, please download and install the .NET SDK of your choice and Visual Studio 2019 Community Edition.

Git Repository on GitHub

One last thing before we start with creating our Blazor WebAssembly project.

You can get the complete code you’ll see during this tutorial series on GitHub.

Here’s the link to the repository: https://github.com/patrickgod/blazorbattles

As you can see, the commits in this repository match the structure of this tutorial series.

So if you’re struggling with your code, please have a look at this repository. I hope it helps to find a solution.

Or just grab the code and build your own browser game with it. Whatever you like.

Anyways, if you still have any problems with the code, you can also reach out to me, of course.

Now let’s create the project.

Jumpstart

Create an ASP.NET Core Hosted Blazor WebAssembly Project

Alright, when you start Visual Studio, choose Create a new project first.

From the templates, we choose a Blazor App. If you can’t find it, just use the search bar on top and look for blazor for instance.

Let’s give this thing a suitable name like BlazorBattles for instance and click Create.

Now it’s getting interesting. We have a bunch of options available here.

First the .NET SDK version. I’d like to use .NET Core 3.1.

Then we can choose between a Blazor Server App and a Blazor WebAssembly App. Well, according to the title of this tutorial series, we should choose Blazor WebAssembly.

If you don’t know the difference, just real quick: A Blazor Server App runs completely on the server. There are no actual web service calls like you might be used to with a typical web application.

The description says that user interactions are handled over a SignalR connection, meaning over web sockets. So the user doesn’t really download the client app to the browser, which is great.

But the big disadvantage is that the server has to handle everything. So if your app has a lot of users, the server has to manage all the interactions of every user, all current states, and so on.

With a Blazor WebAssembly application, the server has a lot less to do, because the client handles the interactions which might be faster for the user - speaking of user experience and offline functionality, for instance - and which is the typical structure of a modern web application.

Maybe you have already built a web application with a .NET back end and a JavaScript framework like Angular, React, or VueJS for the front end. These frameworks handle user interactions as well and make web service calls to the back end.

With Blazor WebAssembly it is the same thing, but you don’t have to write JavaScript.

You can keep writing C# code and even use the same classes for the client and the server. I just love that fact.

So, long story short, we choose the Blazor WebAssembly App.

We don’t need authentication for now. We will implement authentication later by ourselves, which is a great way to learn.

Configure for HTTPS is fine and then comes an important checkbox, we select ASP.NET Core hosted.

With that selection, we already get a server project and a shared project additionally to our client project.

We’ll have a look at these projects in the next chapter. For now, it’s just important to know that this checkbox provides a solution where we can already make use of a Web API. So, a full-stack web application in one solution with C# and .NET only.

That’s it.

At the bottom right you can double-check the used .NET (Core) version and then click Create.

And there’s our new solution. Great!

Let’s open the Solution Explorer on the right and then see what has been created for us.

Solution Overview

So, in the Solution Explorer of Visual Studio, you see three projects, Client, Server, and Shared.

The Client project represents the front end. Here’s where all the Blazor WebAssembly magic will happen.

The Server project will be the home of the Web API and Entity Framework.

And the Shared project will be used to share classes between the client and server projects. This means, building a model once and using it for both the client and the server. You can already see the WeatherForecast model here for instance, but we’ll talk about the example application in the next chapter.

Let’s have a look at the client project first.

The Program.cs file with the Main() method is the starting point. We will mainly use this method to register new services we write by ourselves or services that will be added by new packages.

namespace BlazorBattles.Client
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            var builder = WebAssemblyHostBuilder.CreateDefault(args);
            builder.RootComponents.Add<App>("app");

            builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });

            await builder.Build().RunAsync();
        }
    }
}

You can already see that something is happening here with the HttpClient class, and above that line, a root component is added, which would be the App component we can find in the App.razor file.

<Router AppAssembly="@typeof(Program).Assembly">
    <Found Context="routeData">
        <RouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
    </Found>
    <NotFound>
        <LayoutView Layout="@typeof(MainLayout)">
            <p>Sorry, there's nothing at this address.</p>
        </LayoutView>
    </NotFound>
</Router>

A component in Blazor is a razor file. That's why it's also called a Razor component.

So the App component is the root component where you actually see the use of further components like the Router, the Found and NotFound component, and the RouteView for instance.

The Router component that wraps the other ones, in this case, decides if a route that has been entered in the address bar of the browser is correct or not.

If it is correct, the Found component will be used to display the content of the entered route, if not, the NotFound component will be used. Both components, in turn, use further components, a RouteView and a LayoutView.

And these two make use of the MainLayout. But let’s stick to the LayoutView first. It uses the MainLayout, but the content can already be seen here. It’s a simple text wrapped by a standard HTML paragraph tag.

<LayoutView Layout="@typeof(MainLayout)">
    <p>Sorry, there's nothing at this address.</p>
</LayoutView>

The RouteView though uses the MainLayout but with the content of the actual page, the user wants to see by entering a particular route. And this page can be found in the Pages folder.

We’ll get to that in a second.

Let’s have a quick look at the _Imports.razor file. It’s quite simple, you will find global using directives here. That’s it. If you don’t want to add a reference in a single component, add it here instead.

@using System.Net.Http
@using System.Net.Http.Json
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Components.WebAssembly.Http
@using Microsoft.JSInterop
@using BlazorBattles.Client
@using BlazorBattles.Client.Shared

Okay, next, let’s have a look at the MainLayout in the Shared folder.

@inherits LayoutComponentBase

<div class="sidebar">
    <NavMenu />
</div>

<div class="main">
    <div class="top-row px-4">
        <a href="http://blazor.net" target="_blank" class="ml-md-auto">About</a>
    </div>

    <div class="content px-4">
        @Body
    </div>
</div>

Looks like standard HTML at first glance, right?

Well, the only difference is that it inherits from the LayoutComponentBase class. And when you look at this class, you can see that it has a property called Body of type RenderFragment which is used in the MainLayout with @Body. And that’s where the pages will be rendered.

namespace Microsoft.AspNetCore.Components
{
    //
    // Summary:
    //     Optional base class for components that represent a layout. Alternatively, components
    //     may implement Microsoft.AspNetCore.Components.IComponent directly and declare
    //     their own parameter named Microsoft.AspNetCore.Components.LayoutComponentBase.Body.
    public abstract class LayoutComponentBase : ComponentBase
    {
        protected LayoutComponentBase();

        //
        // Summary:
        //     Gets the content to be rendered inside the layout.
        [Parameter]
        public RenderFragment Body { get; set; }
    }
}

Additionally, you can see another used component, the NavMenu, but we’ll get to that soon.

Do you already see how these things work together?

A component can be used by adding a tag with its exact name. And any page will be rendered in the @Body part of a Layout.

You could build a custom layout if you like and use that one instead of the MainLayout in the App.razor component. Totally up to you.

Anyways, let’s have a look at the pages, for instance, the Index.razor.

@page "/"

<h1>Hello, world!</h1>

Welcome to your new app.

<SurveyPrompt Title="How is Blazor working for you?" />

The crucial part is the @page directive with a string that already is the route for that page. You don’t have to specify that route anywhere else. Just create a component, add that @page directive, and you’re done.

@page "/"

It’s the same with the FetchData and the Counter pages.

Before we have a deeper look at the code, a quick word about the other projects.

The server project first consists of a Program.cs and a Startup.cs file.

In the Startup class we find the ConfigureServices() and the Configure() method.

The ConfigureServices() configures the app’s services, so a reusable component that provides app functionality.

        public void ConfigureServices(IServiceCollection services)
        {

            services.AddControllersWithViews();
            services.AddRazorPages();
        }

We will register services in the future in this method, so they can be consumed in our web service via dependency injection for instance, similar to the Program.cs of the client project.

Please don’t mind all these buzzwords right now…

The Configure() method creates the server app’s request processing pipeline, meaning the method is used to specify how the app responds to HTTP requests.

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
                app.UseWebAssemblyDebugging();
            }
            else
            {
                app.UseExceptionHandler("/Error");
                // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
                app.UseHsts();
            }

            app.UseHttpsRedirection();
            app.UseBlazorFrameworkFiles();
            app.UseStaticFiles();

            app.UseRouting();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapRazorPages();
                endpoints.MapControllers();
                endpoints.MapFallbackToFile("index.html");
            });
        }

As you can see we’re using HttpRedirection, Routing, and so on. With all these Use...() extension methods, we’re adding middleware components to the request pipeline. For instance UseHttpRedirection() adds middleware for redirecting HTTP requests to HTTPS.

Now the Startup class is specified when the app’s host is built. You see that in the Program class in the CreateHostBuilder() method. Here the Startup class is specified by calling the UseStartup() method.

namespace BlazorBattles.Server
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }
}

Regarding the appsettings.json files we only need to know that we can add and modify some configurations here.

More interesting and often used throughout the back end part of this course is the Controllers folder.

The first controller you see here is the generated WeatherForecast demo controller. We’ll get to the details of controllers later. For now, it’s only important to know that we can already call the Get() method here which is actually done by the FetchData component.

        [HttpGet]
        public IEnumerable<WeatherForecast> Get()
        {
            var rng = new Random();
            return Enumerable.Range(1, 7).Select(index => new WeatherForecast
            {
                Date = DateTime.Now.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]
            })
            .ToArray();
        }

I’d say, we do that next.

Example Project Explained

Let’s run the application first and then talk about some files we haven’t talked about yet.

The great thing about Visual Studio and .NET Core hosted Blazor WebAssembly applications is that you can simply start this whole package with that little play button on top. Let’s do exactly that.

The actual starting project is the Server project and Visual Studio will fire up IIS Express with a browser of your choice to start the app.

When you have a close look, you see the text “Loading…”. Where does that come from, you might ask?

Well, the client project has got this folder called wwwroot which is the root of the actual website, and here next to some cascading style sheets and a favicon you can find the actual index.html. And here you find the loading text.

<app>Loading...</app>

Any resources you want to add later, like icons, images, other stylesheets, and so on, have to be added to this wwwroot folder. We will use this place later.

The crazy thing now is, that you can actually debug the client and the server at the same time.

You see, that the counter page increases a counter.

Let’s have a look at the code.

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

It seems like there’s not much to see, but actually, there’s already happening a lot.

You already know the @page directive.

Then you can use the @currentCount variable.

<p>Current count: @currentCount</p>

This integer variable can also be found in the @code block at the bottom.

private int currentCount = 0;

So in this @code block, you’re free to write C# code and use that code above within your HTML code. With the @currentCount variable you already see how data binding is done in Blazor WebAssembly.

And in the button, you can already see event handling.

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

The onclick event, marked with an @ calls the IncrementCount() method. Simple as that.

By the way, if you don’t like having your C# code together with HTML, you can create a code-behind file for your C# code instead.

Now let’s set a breakpoint inside the IncreaseCount() method.

We hit the Click me button and hit the breakpoint. Crazy.

Now, what’s up with the service? Let’s have a look at the FetchData page.

This page actually makes a call to the Web API of the server project. We can see that in the network tab of the console.

Looking at the code, we see a lot of new stuff.

@page "/fetchdata"
@using BlazorBattles.Shared
@inject HttpClient Http

<h1>Weather forecast</h1>

<p>This component demonstrates fetching data from the server.</p>

@if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th>Temp. (C)</th>
                <th>Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    private WeatherForecast[] forecasts;

    protected override async Task OnInitializedAsync()
    {
        forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");
    }

}

First the using directive. We’re referencing the Shared project here, because we’re using the WeatherForecast class.

Then we inject the HttpClient which enables us to make web service calls.

@using BlazorBattles.Shared
@inject HttpClient Http

Inside the table, we see a foreach loop that uses the forecasts received from the service.

        <tbody>
            @foreach (var forecast in forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>

We’ll do all this later by ourselves, so please don’t mind my pacing for now if it’s a bit too fast.

In the @code block we see a new method called OnInitializedAsync(). This thing is part of the component lifecycle and is called, as the name may imply, on the initialization of the component.

    protected override async Task OnInitializedAsync()
    {
        forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");
    }

And in this method we’re using the injected HttpClient to make a Get() call to the WeatherForecast route which would be the WeatherForecastController of the server project, which is, by the way, also using the WeatherForecast class of the Shared project.

Let’s move to that controller and set a breakpoint in the Get() method and then run the app again.

When we open the FetchData page, the breakpoint in the service is hit. Fantastic!

Now, although being able to debug client and server at the same time is great, I like to run the application in another way.

Because with the way I just showed you, you have to stop and run the project by yourself every single time you made some changes to your code. This slows down development.

So instead, I like to use the Package Manager Console with the dotnet watch run command, which rebuilds the project when any code change has been recognized.

There's only one problem: So far this only works for the server project. If we make any changes to the client project, they won’t be recognized. But, of course, we can fix that.

In the project file of the server, we add a new ItemGroup.

  <ItemGroup>
    <Watch Include="..\Client\**\*.razor" />
  </ItemGroup>

With that little change, the application notices any change happening in any razor file of the client project - additionally to any change in the server project.

Now let’s open the Package Manager Console and then first move to the directory of the server.

Now enter dotnet watch run. When the app is running, you already see the URL we have to enter in Chrome.

This URL can also be found in the launchSettings.json files of your projects.

Now the breakpoints won’t be hit, but let’s increase the counter by 2 for instance.

private void IncrementCount()
{
    currentCount += 2;
}

The change will be recognized, the app is rebuilt and we just have to reload the page to see the change.

The same for the server. Let’s return seven forecasts instead of five and reload the page.

    [HttpGet]
        public IEnumerable<WeatherForecast> Get()
        {
            var rng = new Random();
            return Enumerable.Range(1, 7).Select(index => new WeatherForecast
            {
                Date = DateTime.Now.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]
            })
            .ToArray();
        }

Now we see seven forecasts.

You see, this makes developing your Blazor WebAssembly app a lot faster.

One thing we haven’t talked about yet is the NavMenu. But by now, you may already know how this component works.

You see some data binding and event handling with the ToggleNavMenu() function and the NavMenuCssClass variable.

<div class="top-row pl-4 navbar navbar-dark">
    <a class="navbar-brand" href="">BlazorBattles</a>
    <button class="navbar-toggler" @onclick="ToggleNavMenu">
        <span class="navbar-toggler-icon"></span>
    </button>
</div>

<div class="@NavMenuCssClass" @onclick="ToggleNavMenu">
    <ul class="nav flex-column">
        <li class="nav-item px-3">
            <NavLink class="nav-link" href="" Match="NavLinkMatch.All">
                <span class="oi oi-home" aria-hidden="true"></span> Home
            </NavLink>
        </li>
        <li class="nav-item px-3">
            <NavLink class="nav-link" href="counter">
                <span class="oi oi-plus" aria-hidden="true"></span> Counter
            </NavLink>
        </li>
        <li class="nav-item px-3">
            <NavLink class="nav-link" href="fetchdata">
                <span class="oi oi-list-rich" aria-hidden="true"></span> Fetch data
            </NavLink>
        </li>
    </ul>
</div>

@code {
    private bool collapseNavMenu = true;

    private string NavMenuCssClass => collapseNavMenu ? "collapse" : null;

    private void ToggleNavMenu()
    {
        collapseNavMenu = !collapseNavMenu;
    }
}

New though is the NavLink component. This is a built-in component for navigation links.

            <NavLink class="nav-link" href="counter">
                <span class="oi oi-plus" aria-hidden="true"></span> Counter
            </NavLink>

The description already says it all: It’s a component that renders an anchor tag, automatically toggling its active class based on whether its href matches the current URI. And the href would be the string that is used with the @page directives of your pages.

One last thing I want to show you in this example application is the first way of communication between components.

When we switch to the Index.razor again, you see the use of the SurveyPrompt component with a Title.

<SurveyPrompt Title="How is Blazor working for you?" />

This Title is actually a parameter. So the parent component Index can tell the child component SurveyPrompt anything with the help of parameters.

Looking at the SurveyPrompt component, you see the Title property in the @code block, marked by a [Parameter] attribute.

@code {
    // Demonstrates how a parent component can supply parameters
    [Parameter]
    public string Title { get; set; }
}

And then this Title - provided by the parent - is used in the HTML above.

<strong>@Title</strong>

Alright, that should be it for the example application. Already a lot of input I guess.

Let’s make a new Git repository out of this and then start building our browser game with Blazor.

Initialize Git Repository

To initialize a Git repository, on the bottom right of Visual Studio we click on Add to Source Control and choose Git.

And that’s it actually. Now we’ve got a local repository where we can commit our changes and have a history of them.

We could also publish this repository to any remote one or use GitHub or Azure DevOps, for instance. This could also be a private repository. So if you want to save your code to the cloud feel free to do so.

As mentioned earlier, you will find the code of this tutorial series on GitHub as well. So if you have any trouble or just want to play around with the project, feel free to access this project on GitHub, clone the repo, fork it, star it, and so on.

Alright, that’s it for this part of the Blazor WebAssembly Full Stack Bootcamp. Let’s make a game next.

That's it for the first part of this tutorial series. I hope it already was useful to you. To get notified for the next part, simply follow me here on dev.to or subscribe to my newsletter. You'll be the first to know.

See you next time!

Take care.

Next up: Your first Razor component, communication between components with parameters, event callbacks and services, create a new page, and more!

Thumbnail: vector illustration/Shutterstock

But wait, there’s more!

Watch the Blazor WebAssembly Full Stack Bootcamp online course
Subscribe to my newsletter for exclusive content
Get the 5 Software Developer’s Career Hacks for free.
Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.

SQLite & Data Seeding with Entity Framework Core

Patrick God — Mon, 14 Sep 2020 21:38:52 +0000

SQLite & Data Seeding with Entity Framework Core

Introduction

If you don’t want to use SQL Server for your web application, you might want to choose SQLite.

Many students want to use a database that is cross-platform, lightweight, and usable in many different scenarios such as smartphones, for instance. In that case, SQLite is a popular choice.

So, it was time to add this chapter with example implementations for SQLite.

We will configure the application for SQLite, start the migrations from scratch and use the DB Browser for SQLite to have a look at the database.

Additionally, you will learn how to seed the database. This means, you don’t have to add users, characters, skills, and so on manually. You will learn how to do this with code. Very convenient and time-saving.

Let’s start with SQLite first.

New Package, ConnectionString & Configuration

The very first thing we have to do to be able to use a SQLite database is adding a new package, which would be Microsoft.EntityFrameworkCore.Sqlite.

Let’s do that in the terminal with the command dotnet add package Microsoft.EntityFrameworkCore.Sqlite.

After the installation, you should see the change in your project file.



<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="3.1.8" />

After that, we have to change or add the connection string for the SQLite database. Since this database is a file, the connection string is quite simple.

In the appsettings.json file we add a new string, like SqliteConnection, and set it to Data Source=dotnetrpg.db. Done.



"ConnectionStrings": {
  "DefaultConnection": "Server=localhost\\SQLEXPRESS; Database=dotnet-rpg; Trusted_Connection=true;",
  "SqliteConnection" : "Data Source=dotnetrpg.db"
},

As soon as we add our migrations and update the database for the first time, Entity Framework will create this exact file.

Finally, we make a change to the ConfigureServices() method in the Startup.cs. Instead of SQL Server, we’re now using SQLite and the new connection string.



services.AddDbContext<DataContext>(x => x.UseSqlite(Configuration.GetConnectionString("SqliteConnection")));

Alright. We’re ready to create the SQLite database.

Create the SQLite Database

Since the DataContext is now configured to use a SQLite database, the existing migration files won’t work.

The easiest way to create the SQLite database with code-first migration is to delete the migrations folder and add a new initial migration.

As soon as you have removed the folder with all migration files, add a migration again with dotnet ef migrations add Initial.

The generated files should look familiar. Tables will be created, keys will be set, and so on.

We create the database file with dotnet ef database update.

Now we need a tool to open the file and browse through the database.

Use the DB Browser for SQLite

Probably the most used tool to create, design, and edit database files compatible with SQLite would be the DB Browser for SQLite. You can download it on sqlitebrowser.org and it is available for Windows, macOS, and Linux. You see, we really are cross-platform here.

So please download the DB Browser and install it. There is also a portable version available.

After the installation, please open the database file of our web application which can be found in the root directory of the project.

Please make yourself a bit familiar with the DB Browser.

You find the database structure with all the tables in the first tab. To see the content of a table you can select the second tab “Browse Data” and select the table you want to see.

When you add, edit or delete a record, make sure to click the “Write Changes” button in the top menu to make your changes persistent.

That’s it already. Any web service call works as before but now stores the data in the SQLite database - thanks to Entity Framework.

But before you start adding all the data manually in the DB Browser, let’s have a look at how to seed the database programmatically.

Data Seeding Preparations

The great thing about data seeding is that you configure your seed or test data once and - in a perfect world - never have to worry about adding data to your database before testing any features.

In our case, we want to seed users with a character, and these RPG characters should already have skills and a weapon.

All that is done in our DataContext class. But before we can start, we have to make some small changes to our code.

First, we go to the Character class and add another property, the UserId. This is necessary because we have to define this foreign key when seeding the data. Setting a User object is not necessary and wouldn’t work. We have to set the Id of the User.

The next thing to modify is the CreatePasswordHash() method of the AuthRepository. To be more specific, we move this method to a static Utility class.

The reason for that is that we want to seed users, but can’t inject the AuthRepository into the DataContext to call the Register() method, for instance.

When seeding users though, we have to set every property. This means even the Id, although it is automatically incremented by the database when inserting a new user, and also the password hash.

And because I don’t want to set a byte array manually, I would like to use the CreatePasswordHash() method. You will see how to seed users in a minute. For now, let’s just make the change.

We can cut the CreatePasswordHash() method from the AuthRepository, create a static Utility class in the Data folder, paste the method and also make it public static.



namespace dotnet_rpg.Data
{
    public static class Utility
    {
         public static void CreatePasswordHash(string password, out byte[] passwordHash, out byte[] passwordSalt)
        {
            using (var hmac = new System.Security.Cryptography.HMACSHA512())
            {
                passwordSalt = hmac.Key;
                passwordHash = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(password));
            }
        }
    }
}

In the Register() method of the AuthRepository we now have to use this new class and that’s it.



Utility.CreatePasswordHash(password, out byte[] passwordHash, out byte[] passwordSalt);

These are all the preparations. Next, we start the data seeding with skills.

Seeding Skills

As mentioned before, the whole data seeding happens in the DataContext. To be more specific, we’re using the OnModelCreating() method. We have already defined a key and a default value here. Next is the seed data.

In this case, we also configure a certain entity and then call the method HasData() and give it some, well... data.

Let’s start with skills, because they have no relations, hence no other entities need to be seeded before we can add skills.



modelBuilder.Entity<Skill>().HasData(
    new Skill { Id = 1, Name = "Fireball", Damage = 30 },
    new Skill { Id = 2, Name = "Frenzy", Damage = 20 },
    new Skill { Id = 3, Name = "Blizzard", Damage = 50});

To test that, we add a new migration with dotnet ef migrations add SkillSeeding and then update the database with dotnet ef database update, but I have to warn you, this will most likely not work.

You’re probably getting the following error when you want to update the database.

You see, using SQLite with Entity Framework Core is different than using SQL Server. The SQLite provider has some migrations limitations. Most of these limitations are a result of limitations in the underlying SQLite database engine and are not specific to Entity Framework. That’s what the official documentation says.

So, the DropForeignKey operation does not work with .NET Core 3.1.

Since we created the database from scratch anyways, we can delete it again, delete the migrations folder as well and then add a new initial migration. This time, the database update should work.

After that, we can see the skills in the Skills table with the DB Browser.

Beautiful.

Seeding Entities with Relations

Now comes the rest. We create Users, Characters, Weapons, and CharacterSkills. We don’t have to configure these entities in a specific order but we have to pay attention to the foreign keys. Characters are related to Users, Weapons and CharacterSkills are related to Characters (and Skills).

Let’s start with the Users. The code is similar to the seeding of the Skills and thanks to our preparations, we can use the CreatePasswordHash() method first to get the proper hash and salt values. And yes, since this is test data, we can use the same hash and salt values for several users.



Utility.CreatePasswordHash("123456", out byte[] passwordHash, out byte[] passwordSalt);

modelBuilder.Entity<User>().HasData(
    new User { Id = 1, PasswordHash = passwordHash, PasswordSalt = passwordSalt, Username = "User1" },
    new User { Id = 2, PasswordHash = passwordHash, PasswordSalt = passwordSalt, Username = "User2" }
);

Now we can seed Characters and set the proper values.



modelBuilder.Entity<Character>().HasData
    new Character { 
        Id = 1, 
        Name = "Frodo",
        Class = RpgClass.Knight,
        HitPoints = 100,
        Strength = 15,
        Defense = 10,
        Intelligence = 10,
        UserId = 1 },
    new Character { 
        Id = 2, 
        Name = "Raistlin",
        Class = RpgClass.Mage,
        HitPoints = 100,
        Strength = 5,
        Defense = 5,
        Intelligence = 20,
        UserId = 2 }
);

And now we can do the same for Weapons and CharacterSkills.



modelBuilder.Entity<Weapon>().HasData(
    new Weapon { Id = 1, Name = "The Master Sword", Damage = 20, CharacterId = 1 },
    new Weapon { Id = 2, Name = "Crystal Wand", Damage = 5, CharacterId = 2 }
);
modelBuilder.Entity<CharacterSkill>().HasData(
    new CharacterSkill { CharacterId = 1, SkillId = 2 },
    new CharacterSkill { CharacterId = 2, SkillId = 1 },
    new CharacterSkill { CharacterId = 2, SkillId = 3 }
);

The last step is a new migration again. So we enter dotnet ef migrations add FinalSeeding and then update the database with dotnet ef database update.

After the update, we can admire our seed data in the DB Browser. Go for it!

And we can already test our data with a fight. Shall we?

Start the app with dotnet watch run, fire up Postman, and use the URL http://localhost:5000/fight for a POST request.

The body should be an array with the ids 1 and 2.



{
    "characterIds" : [1,2]
}

Hit “Send” and we get a beautiful fighting log.



{
    "data": {
        "log": [
            "Frodo attacks Raistlin using The Master Sword with 27 damage.",
            "Raistlin attacks Frodo using Fireball with 37 damage.",
            "Frodo attacks Raistlin using Frenzy with 20 damage.",
            "Raistlin attacks Frodo using Crystal Wand with 0 damage.",
            "Frodo attacks Raistlin using Frenzy with 29 damage.",
            "Raistlin attacks Frodo using Blizzard with 59 damage.",
            "Frodo attacks Raistlin using The Master Sword with 23 damage.",
            "Raistlin attacks Frodo using Crystal Wand with 6 damage.",
            "Frodo has been defeated!",
            "Raistlin wins with 1 HP left!"
        ]
    },
    "success": true,
    "message": null
}

I hope this was helpful. If you have any questions or more feature requests, feel free to contact me. And as always, the code is available on GitHub.

See you next time!

Take care.

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.

Role-Based Authentication in .NET Core 3.1

Patrick God — Mon, 10 Aug 2020 21:02:24 +0000

Role-Based Authentication in .NET Core 3.1

Introduction

You have asked for it, so here it is: Role-based authentication.

In this chapter, you will learn how to add a role to a User, read that role, and use it to change the behavior of a service and extend the [Authorize] attribute.

To be more specific, we will change the behavior of the GetAllCharacters() method.

Currently, users can only see the characters they have created, but if a user has got the Admin role, this user will be able to see all the characters of every user.

To realize that, we first add a new property to the User class, run another migration, add a new Claim to the JSON web token, and then read that new Claim to decide what the user is allowed to see.

Let’s start.

New User Property: Role & A New Migration

First of all the User gets a new property called Role which is a string.

Additionally, we add an attribute to that property, and this attribute is called [Required].

To make this work, we need the System.ComponentModel.DataAnnotations using directive.

public class User
{
    public int Id { get; set; }
    public string Username { get; set; }
    public byte[] PasswordHash { get; set; }
    public byte[] PasswordSalt { get; set; }
    public List<Character> Characters { get; set; }
    [Required]
    public string Role { get; set; }
}

With the [Required] attribute, we tell Entity Framework that this property is not nullable. So we have to set a value for a role. Since this property is a string, the default value is simply an empty string.

Let’s change that and set the default value to “Player”. We do that in the DataContext class in the OnModelCreating() method.

For the User entity, we set the default value of the property Role with the method HasDefaultValue().

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<CharacterSkill>()
        .HasKey(cs => new { cs.CharacterId, cs.SkillId });

    modelBuilder.Entity<User>()
        .Property(user => user.Role).HasDefaultValue("Player");
}

Now, when we run another migration, all the users that already exist get the “Player” role and every new user will get this role as well.

Let’s add another migration with dotnet ef migrations add Role.

As you can see in the Up() method of this new migration, a new column is added which is not nullable and with the default value “Player”. Great.

protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.AddColumn<string>(
        name: "Role",
        table: "Users",
        nullable: false,
        defaultValue: "Player");
}

Let’s update the database with dotnet ef database update.

When this is done, we can see the new column and the “Player” role for every user in the database.

And when we register a new user with Postman, even the new user gets this role.

Perfect. This works so far. Now we have to add this role to the user’s token.

Extend the JSON Web Token with another Claim

Adding this role to the user’s token is actually quite simple. It’s just a new Claim we have to add.

So in the AuthRepository in the CreateToken() method, we add a new Claim to the claims list.

The type is ClaimTypes.Role and the value is the new Role property of the user object.

private string CreateToken(User user)
{
    List<Claim> claims = new List<Claim>
    {
        new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
        new Claim(ClaimTypes.Name, user.Username),
        new Claim(ClaimTypes.Role, user.Role)
    };
// ...

That’s it.

But let’s see if this really worked.

We log a user in, copy the resulting token, and then use the debugger of jwt.io in the browser.

We can paste the token, and indeed we see the new claim. The role of the user is “Player”.

Nice. Let’s finish this new feature now, by changing the behavior of a service and restricting access to a specific role.

Restrict Controller Access & Change Service Behavior

The goal is to change the behavior of the GetAllCharacters() method in the CharacterService.

Before we do that, I want to show you how you can control access to a method or a whole class.

In the CharacterController, we’re already using the [Authorize] attribute. So, only authenticated users can access this controller.

To restrict access even further, we can simply add “Roles” to that attribute, for instance, the “Player” role.

[Authorize(Roles = "Player")]
[ApiController]
[Route("[controller]")]
public class CharacterController : ControllerBase
{
  // ...

Now, this wouldn’t change anything for our authenticated testuser, so let’s give this user the role “Admin” in the database manually.

We have to log in the user again with Postman to get the new token and then we use this token to get all of the user’s characters.

But as you can see, this is not possible. We get a 403 Forbidden.

So let’s add the role “Admin” now to the [Authorize] attribute. We can do that by simply adding a comma and the second role.

[Authorize(Roles = "Player,Admin")]

When we now want to see the user’s characters, it does work.

But let’s really make use of an “Administrator” role.

Simple “Players” can only see the characters they have created. An admin should see all the characters.

So let’s move to the CharacterService and add a little method called GetUserRole() similar to the method GetUserId().

Only this time the return type is a string and we want the value of the claim type Role.

private string GetUserRole() => _httpContextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.Role);

Alright. And now in the GetAllCharacters() method we check if the user role is equal to “Admin” and if so, we return all characters, and if not, we use the old line where we filter the characters by the User.Id.

List<Character> dbCharacters = 
    GetUserRole().Equals("Admin") ? 
    await _context.Characters.ToListAsync() :
    await _context.Characters.Where(c => c.User.Id == GetUserId()).ToListAsync();

When we test that again with Postman, we even get the characters of the other users. Exactly what we want.

So, this works fine, and that’s how you add role-based authentication.

As always, you can get the source code in the corresponding GitHub repository and if you have any further feature requests or questions, don’t hesitate to contact me.

See you next time!

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.

I started a tutorial series about Blazor WebAssembly - Should I continue?

Patrick God — Fri, 07 Aug 2020 14:55:00 +0000

The title says it all. I started a new tutorial series on how to build a blog with Blazor WebAssembly and published the first video on YouTube.

Here's the first episode:

The thing is, this tutorial series is really spontanous. I've got no script, no preparation, nothing. I just wanted to try something new.

It kinda feels like a livestream to me, because you see me failng (a lot), probably debugging or searching the web for implementations and fixes. So, it's actually like real development work. ;)

Anyways, if you have the time, I'd really like to get your feedback and maybe ideas for future episodes. I don't know if video tutorials like that are useful for you. But if they are, I'd be happy to go on.

My rough plan is to build a blog with token authentication using JSON web tokens, a Web API with Entity Framework and a SQLite database.

So, again, if you like that kind of spontanous tutorials, please tell me. Thanks a lot!

Take care,
Patrick

More Than Just CRUD with .NET Core 3.1 - Part 2

Patrick God — Mon, 13 Apr 2020 13:02:33 +0000

More Than Just CRUD with .NET Core 3.1 (continued)

Start a Fight

Again we start with new DTOs. First, we create a FightRequestDto with only one property, a List of int values for the CharacterIds. Do you see the possibilities here? We could not only let two RPG characters fight against each other, but we could also start a deathmatch!

using System.Collections.Generic;

namespace dotnet_rpg.Dtos.Fight
{
    public class FightRequestDto
    {
        public List<int> CharacterIds { get; set; }
    }
}

The result of the automatic fight or deathmatch should also look a bit different. How about some kind of fighting log that will simply tell us with some sentences how the battle took place?

We create a new FightResultDto class, again with only one property, a List of string values. This will be our Log and we can already initialize this List so that we can easily add new entries right away later.

using System.Collections.Generic;

namespace dotnet_rpg.Dtos.Fight
{
    public class FightResultDto
    {
        public List<string> Log { get; set; } = new List<string>();
    }
}

Off to the IFightService interface. We add a new method called Fight() which returns the FightResultDto and takes a FightRequestDto as request.

Task<ServiceResponse<FightResultDto>> Fight(FightRequestDto request);

Regarding the FightController we can copy another method again, replace the method name as well as the DTO and the method of the _fightService, and we can also remove the route so that this method becomes the default POST call of this controller.

[HttpPost]
public async Task<IActionResult> Fight(FightRequestDto request)
{
    return Ok(await _fightService.Fight(request));
}

Now it’s getting interesting. Let’s create the Fight() method in the FightService. We implement the interface and add the async keyword.

Then we initialize the ServiceResponse and also initialize the Data with a new FightResultDto object.

ServiceResponse<FightResultDto> response = new ServiceResponse<FightResultDto>
{
    Data = new FightResultDto()
};

Next, we add our default try/catch block as always and return a failing response in case of an error.

Inside the try-block, we want to grab all the given RPG characters. Remember, this could also be a battle with dozens of fighters - sounds great, huh?

To get the characters we access the _context as usual, include the Weapon, the CharacterSkills and the Skill and then we use the function Where to get all the characters from the database that match the given IDs. We do that with Where(c => request.CharacterIds.Contains(c.Id)) and then turn the result into a List with ToListAsync().

List<Character> characters =
    await _context.Characters
    .Include(c => c.Weapon)
    .Include(c => c.CharacterSkills).ThenInclude(cs => cs.Skill)
    .Where(c => request.CharacterIds.Contains(c.Id)).ToListAsync();

Alright, we’ve got our fighters. Now we define a boolean variable called defeated, set it to false and start two loops - a while loop and a foreach. The while loop stops when the first character is defeated. The idea behind the foreach is that every character will attack in order.

bool defeated = false;
while (!defeated)
{
    foreach (Character attacker in characters)
    {

    }
}

Inside the foreach loop we grab all the opponents of the attacker first. We do that with the help of the Where() function again by simply filtering all characters that don’t have the Id of the attacker.

Then we randomly choose one opponent. We do that with new Random().Next() and then pass the opponents.Count. That way, we get a random number we can use as an index for the opponents list.

List<Character> opponents = characters.Where(c => c.Id != attacker.Id).ToList();
Character opponent = opponents[new Random().Next(opponents.Count)];

Next, we declare two variables we will use for the resulting log. The damage which is 0 and attackUsed as an empty string. You guessed it, I want to see the used weapon or skill of every single attack.

int damage = 0;
string attackUsed = string.Empty;

The next step is to decide if the attacker uses his weapon or one of his skills. To do that, we define a boolean variable useWeapon and throw a die again with new Random().Next(2). If the result is 0 we choose the weapon, if not, we choose a skill.

bool useWeapon = new Random().Next(2) == 0;
if (useWeapon)
{
}
else
{
}

Now we can set the name of the used attack and then already calculate the damage. Since we did that already in the WeaponAttack() method, let’s extract this part and create a new method we can reuse. We can do that by selecting the code, open the quick-fix menu and choose Extract method.

We can call this new method DoWeaponAttack() for instance.

private static int DoWeaponAttack(Character attacker, Character opponent)
{
    int damage = attacker.Weapon.Damage + (new Random().Next(attacker.Strength));
    damage -= new Random().Next(opponent.Defense);
    if (damage > 0)
        opponent.HitPoints -= (int)damage;
    return damage;
}

So now we can use this method and pass the attacker and the opponent to get the damage value and already decrease the HitPoints of the opponent.

if (useWeapon)
{
    attackUsed = attacker.Weapon.Name;
    damage = DoWeaponAttack(attacker, opponent);
}

Regarding the damage for a Skill we can also extract the calculation from the SkillAttack() method and call this method DoSkillAttack(). You see that we have to pass an attacker, an opponent and a characterSkill this time.

private static int DoSkillAttack(Character attacker, Character opponent, CharacterSkill characterSkill)
{
    int damage = characterSkill.Skill.Damage + (new Random().Next(attacker.Intelligence));
    damage -= new Random().Next(opponent.Defense);
    if (damage > 0)
        opponent.HitPoints -= (int)damage;
    return damage;
}

Great. So, we can use this new method for the damage, but first, we have to get a CharacterSkill.

Again we choose one randomly from the list of CharacterSkills of our attacker. We do that with new Random().Next(attacker.CharacterSkills.Count). This will be the index of our CharacterSkill we store in the variable randomSkill.

With this randomSkill variable, we can now set the name of the attackUsed by setting the Skill.Name and finally calculate the damage with the DoSkillAttack() method and give this method the attacker, the opponent and the attacker.CharacterSkill[randomSkill].

else
{
    int randomSkill = new Random().Next(attacker.CharacterSkills.Count);
    attackUsed = attacker.CharacterSkills[randomSkill].Skill.Name;
    damage = DoSkillAttack(attacker, opponent, attacker.CharacterSkills[randomSkill]);
}

Alright, we’ve got our attacks.

That’s all the information we need to add this attack to the log. I would like to add a sentence that looks like “attacker.Name attacks opponent.Name using attackUsed with damage damage” where the damage value has to be above or equal 0. Nice.

response.Data.Log.Add($"{attacker.Name} attacks {opponent.Name} using {attackUsed} with {(damage >= 0 ? damage : 0)} damage.");

We are almost done. Now we have to decide what to do if an opponent has been defeated. So, in case the opponent.HitPoints are 0 or less we set the variable defeated to true. We increase the Victories of the attacker and the Defeats of the opponent. We can add new sentences to our log! Something like “opponent.Name has been defeated!” and “attacker.Name wins with attacker.HitPoints HP left!”. And finally, we stop the fight and leave the loop with break.

if (opponent.HitPoints <= 0)
{
    defeated = true;
    attacker.Victories++;
    opponent.Defeats++;
    response.Data.Log.Add($"{opponent.Name} has been defeated!");
    response.Data.Log.Add($"{attacker.Name} wins with {attacker.HitPoints} HP left!");
    break;
}

After that, we increase the Fights value of all characters in another forEach and also reset the HitPoints for the next fight.

characters.ForEach(c =>
{
    c.Fights++;
    c.HitPoints = 100;
});

And then we update all characters in the database with _context.Characters.UpdateRange(characters) and save everything as usual with SaveChangesAsync().

_context.Characters.UpdateRange(characters);
await _context.SaveChangesAsync();

And that’s it! The automatic fight may begin!

public async Task<ServiceResponse<FightResultDto>> Fight(FightRequestDto request)
{
    ServiceResponse<FightResultDto> response = new ServiceResponse<FightResultDto>
    {
        Data = new FightResultDto()
    };
    try
    {
        List<Character> characters =
            await _context.Characters
            .Include(c => c.Weapon)
            .Include(c => c.CharacterSkills).ThenInclude(cs => cs.Skill)
            .Where(c => request.CharacterIds.Contains(c.Id)).ToListAsync();

        bool defeated = false;
        while (!defeated)
        {
            foreach (Character attacker in characters)
            {
                List<Character> opponents = characters.Where(c => c.Id != attacker.Id).ToList();
                Character opponent = opponents[new Random().Next(opponents.Count)];

                int damage = 0;
                string attackUsed = string.Empty;

                bool useWeapon = new Random().Next(2) == 0;
                if (useWeapon)
                {
                    attackUsed = attacker.Weapon.Name;
                    damage = DoWeaponAttack(attacker, opponent);
                }
                else
                {
                    int randomSkill = new Random().Next(attacker.CharacterSkills.Count);
                    attackUsed = attacker.CharacterSkills[randomSkill].Skill.Name;
                    damage = DoSkillAttack(attacker, opponent, attacker.CharacterSkills[randomSkill]);
                }

                response.Data.Log.Add($"{attacker.Name} attacks {opponent.Name} using {attackUsed} with {(damage >= 0 ? damage : 0)} damage.");

                if (opponent.HitPoints <= 0)
                {
                    defeated = true;
                    attacker.Victories++;
                    opponent.Defeats++;
                    response.Data.Log.Add($"{opponent.Name} has been defeated!");
                    response.Data.Log.Add($"{attacker.Name} wins with {attacker.HitPoints} HP left!");
                    break;
                }
            }
        }

        characters.ForEach(c =>
        {
            c.Fights++;
            c.HitPoints = 100;
        });

        _context.Characters.UpdateRange(characters);
        await _context.SaveChangesAsync();
    }
    catch (Exception ex)
    {
        response.Success = false;
        response.Message = ex.Message;
    }
    return response;
}

But before we start a fight, let’s prepare a third character, so that we actually get a deathmatch.

We already got Sam. In the SQL Server Management Studio, we can give him a new weapon directly. Maybe the Sting with a damage value of 10.

Also, we can add a new Skill, like an Iceball which makes 15 damage.

Then we add the skills Frenzy and Iceball to Sam in the CharacterSkills table.

Alright, let’s make sure that every character has 100 hit points and then we can start.

The URL in Postman is http://localhost:5000/fight/, the HTTP method is POST and the body can already be an array of three characterIds.

{
    "characterids" : [2,4,5]
}

Let’s fight!

{
    "data": {
        "log": [
            "Sam attacks Frodo using Sting with 19 damage.",
            "Raistlin attacks Frodo using Fireball with 33 damage.",
            "Frodo attacks Raistlin using The Master Sword with 28 damage.",
            "Sam attacks Raistlin using Sting with 19 damage.",
            "Raistlin attacks Frodo using Crystal Wand with 7 damage.",
            "Frodo attacks Sam using The Master Sword with 17 damage.",
            "Sam attacks Raistlin using Frenzy with 21 damage.",
            "Raistlin attacks Frodo using Crystal Wand with 6 damage.",
            "Frodo attacks Raistlin using Frenzy with 19 damage.",
            "Sam attacks Frodo using Iceball with 21 damage.",
            "Raistlin attacks Frodo using Blizzard with 51 damage.",
            "Frodo has been defeated!",
            "Raistlin wins with 13 HP left!"
        ]
    },
    "success": true,
    "message": null
}

And that’s how a deathmatch looks like. A beautiful use of different weapons and skills. You see the whole course of the fight.

Feel free to start a couple of more battles, so that the Victories and Defeats of the RPG characters change.

We will use these values to display a highscore next.

Highscore: Sort & Filter Entities

To receive a highscore or a ranking of all RPG characters that have ever participated in a fight, we need a GET method and a new DTO for the result. A request object is not necessary.

Let’s start with the DTO. In the Fight folder, we create the C# class HighscoreDTO. The properties I would like to see are the Id of the character, the Name and of course the number of Fights, Victories and Defeats.

namespace dotnet_rpg.Dtos.Fight
{
    public class HighscoreDTO
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public int Fights { get; set; }
        public int Victories { get; set; }
        public int Defeats { get; set; }
    }
}

We will use AutoMapper to map the Character information to the HighscoreDTO later, so let’s create a new map in our AutoMapperProfile class.

CreateMap<Character, HighscoreDTO>();

Okay. Next, we add a new method to the IFightService interface called GetHigscore() which doesn’t take any arguments but it returns a ServiceResponse with a List of HighscoreDTO instances.

Task<ServiceResponse<List<HighscoreDTO>>> GetHighscore();

In the FightController, we also add the new GetHighscore() method with no parameter and even no attribute, because this will be our default GET call. We simply use the method _fightService.GetHighscore() and that’s it.

public async Task<IActionResult> GetHighscore()
{
    return Ok(await _fightService.GetHighscore());
}

Now the FightService. First, we inject the IMapper to be able to map the characters to the HighscoreDTO. We initialize the field from this parameter, add the underscore and also the AutoMapper using directive.

private readonly DataContext _context;
private readonly IMapper _mapper;
public FightService(DataContext context, IMapper mapper)
{
    _mapper = mapper;
    _context = context;
}

Then we can implement the interface and start writing the code for the GetHighscore() method. We start with the async keyword.

Then, we want the characters, of course. In this example we only want to see the characters that have participated in a fight, so Where the Fights value is greater than 0.

And then we want to see a ranking, so we use OrderByDescending() to order the characters by their Victories. If the number of Victories should be the same for some characters, we can then order by their Defeats ascending by using ThenBy(). In the end, we turn the result to a List.

List<Character> characters = await _context.Characters
    .Where(c => c.Fights > 0)
    .OrderByDescending(c => c.Victories)
    .ThenBy(c => c.Defeats)
    .ToListAsync();

Now we can already create the response. If you want, you can use var for that. It’s controversial whether using var is a best practice or not. I think in the case of initializing an object of a long type name, it is okay to do so. In the end, it’s still strongly typed.

Anyways, we initialize the ServiceResponse and already set the Data by mapping all characters to a HighscoreDTO. We do that with characters.Select() and then use the _mapper with the Map() function for every character and turn that result also into a List.

var response = new ServiceResponse<List<HighscoreDTO>>
{
    Data = characters.Select(c => _mapper.Map<HighscoreDTO>(c)).ToList()
};

And finally we return the response. Done!

public async Task<ServiceResponse<List<HighscoreDTO>>> GetHighscore()
{
    List<Character> characters = await _context.Characters
        .Where(c => c.Fights > 0)
        .OrderByDescending(c => c.Victories)
        .ThenBy(c => c.Defeats)
        .ToListAsync();
    var response = new ServiceResponse<List<HighscoreDTO>>
    {
        Data = characters.Select(c => _mapper.Map<HighscoreDTO>(c)).ToList()
    };
    return response;
}

Testing this is simple. In Postman we use the URL http://localhost:5000/fight/ and this time the HTTP method is GET. Hitting “Send” returns our honorable fighters in the right order.

{
    "data": [
        {
            "id": 4,
            "name": "Raistlin",
            "fights": 30,
            "victories": 14,
            "defeats": 9
        },
        {
            "id": 5,
            "name": "Frodo",
            "fights": 30,
            "victories": 11,
            "defeats": 11
        },
        {
            "id": 2,
            "name": "Sam",
            "fights": 30,
            "victories": 5,
            "defeats": 10
        }
    ],
    "success": true,
    "message": null
}

Beautiful!

Summary

Well, congratulations! You have completed the whole course. You can be proud of yourself. I certainly am.

You learned how to build a Web API with all CRUD operations using the HTTP methods GET, POST, PUT and DELETE in .NET Core.

After implementing all these operations you learned how to store your entities and save your changes in a SQL Server database with Entity Framework Core. You utilized code-first migration for that.

But not everybody should have access to your entities. That’s why you added authentication to your web service. Users have to register and authenticate to get access to their data.

Additionally, you not only learned how to hash a password and verify it again, but you also implemented the use of JSON web tokens. With the help of that token, the user doesn’t have to send her credentials with every call. The token does the job for us.

Then you covered advanced relationships in Entity Framework Core and the SQL Server database. By the example of users, RPG characters, weapons, and skills, you implemented one-to-one, one-to-many and many-to-many relationships.

And finally, you got creative by letting your RPG characters fight against each other and find the best of them all.

I hope you’ve got many many insights and new skills for yourself.

Now it’s up to you. Be creative, use your new knowledge and build something amazing!

Good luck & happy coding! :)

That's it for the last part of this tutorial series. I hope it was useful for you. For more tutorials and online courses, simply follow me here on dev.to or subscribe to my newsletter. You'll be the first to know.

See you next time!

Take care.

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.

More Than Just CRUD with .NET Core 3.1

Patrick God — Mon, 06 Apr 2020 06:28:32 +0000

More Than Just CRUD with .NET Core 3.1

Introduction

It is time to let our RPG characters fight.

In the upcoming lectures, we will build a service with functions to let our characters attack another character with a weapon or with one of their skills.

Additionally, we implement a function to let characters fight by themselves until one of them, well, has no hit points anymore.

This will result in victories and defeats which is some kind of highscore we can use to display our RPG characters in a certain order.

So, with no further ado, let the games begin!

Prepare to Fight!

While you weren’t watching, I added some relations between characters, weapons, and skills so that we have characters available to fight against each other. It’s not necessary, but maybe prepare one or two characters yourself so that you can use them for the upcoming implementations.

For now, we’ve got Frodo with the Master Sword and the skill Frenzy, and Raistlin with the Crystal Wand and the skills Fireball and Blizzard. I’m really curious about how they will compete.

Anyways, to count the upcoming fights, victories, and defeats, let’s add exactly these three properties as int to the Character model.

public class Character
{
    public int Id { get; set; }
    public string Name { get; set; } = "Frodo";
    public int HitPoints { get; set; } = 100;
    public int Strength { get; set; } = 10;
    public int Defense { get; set; } = 10;
    public int Intelligence { get; set; } = 10;
    public RpgClass Class { get; set; } = RpgClass.Knight;
    public User User { get; set; }
    public Weapon Weapon { get; set; }
    public List<CharacterSkill> CharacterSkills { get; set; }
    public int Fights { get; set; }
    public int Victories { get; set; }
    public int Defeats { get; set; }
}

We can also add them to the GetCharacterDto.

public class GetCharacterDto
{
    public int Id { get; set; }
    public string Name { get; set; } = "Frodo";
    public int HitPoints { get; set; } = 100;
    public int Strength { get; set; } = 10;
    public int Defense { get; set; } = 10;
    public int Intelligence { get; set; } = 10;
    public RpgClass Class { get; set; } = RpgClass.Knight;
    public GetWeaponDto Weapon { get; set; }
    public List<GetSkillDto> Skills { get; set; }
    public int Fights { get; set; }
    public int Victories { get; set; }
    public int Defeats { get; set; }
}

Now let’s add these properties to the database. First, we add a new migration with dotnet ef migrations add FightProperties.

You see that the migration will add three new columns to the Characters table with 0 as the default value. Exactly what we need.

protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.AddColumn<int>(
        name: "Defeats",
        table: "Characters",
        nullable: false,
        defaultValue: 0);
    migrationBuilder.AddColumn<int>(
        name: "Fights",
        table: "Characters",
        nullable: false,
        defaultValue: 0);
    migrationBuilder.AddColumn<int>(
        name: "Victories",
        table: "Characters",
        nullable: false,
        defaultValue: 0);
}

Let’s update the database with dotnet ef database update.

After the update, we can see the new columns in the SQL Server Management Studio.

Next would already be a FightService with the corresponding interface and controller.

We create a new folder FightService and add the C# classes IFightService and FightService which implements the interface.

namespace dotnet_rpg.Services.FightService
{
    public class FightService : IFightService
    {

    }
}

After that, we create the FightController for the web service calls.

We add the ControllerBase class and the [Route()] and [ApiController] attribute but leave out authentication. Of course, it would make sense to add authentication here, but I think you know how to implement it now and for this example, it’s sufficient to just let the RPG characters fight without the permission of their respective owners.

using Microsoft.AspNetCore.Mvc;

namespace dotnet_rpg.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class FightController : ControllerBase
    {

    }
}

We can also already add a constructor to the FightController which injects the FightService.

public class FightController : ControllerBase
{
    private readonly IFightService _fightService;
    public FightController(IFightService fightService)
    {
        _fightService = fightService;
    }
}

Alright, and finally we register the FightService in the Startup.cs file with services.AddScoped().

services.AddScoped<IFightService, FightService>();

Great! So far the preparations. Coming up next, we implement a way to attack a character with a weapon.

Attack with Weapons

The idea behind attacking other characters with a weapon is that we define an attacker and an opponent and use the weapon of the attacker (remember there can only be one weapon) to fight against the opponent. Pretty simple actually.

To start, we need some DTOs for the request and the result. So, let’s create a Fight folder and the C# class WeaponAttackDto which only consists of the AttackerId and the OpponentId.

namespace dotnet_rpg.Dtos.Fight
{
    public class WeaponAttackDto
    {
        public int AttackerId { get; set; }
        public int OpponentId { get; set; }
    }
}

Since the attacker can only have one weapon, we only need to know who the attacker is. No need for a weaponId.

For the response, we create a new C# class called AttackResultDto. We can put anything we want in there. For me, it’s interesting to know the names of the attacker and the opponent, their resulting hit points and the damage that was taken.

namespace dotnet_rpg.Dtos.Fight
{
    public class AttackResultDto
    {
        public string Attacker { get; set; }
        public string Opponent { get; set; }
        public int AttackerHP { get; set; }
        public int OpponentHP { get; set; }
        public int Damage { get; set; }
    }
}

Alright, that’s it for the DTOs. Next, we add a constructor to the FightService class where we only inject the DataContext to access the Characters of the database.

A short side note about that. In a minute we will get certain characters by their Id. We have already implemented that in the CharacterService. So we could actually inject the ICharacterService and use the method GetCharacterById() here. But we would have to use an authenticated user for that which would take a bit more effort during the tests and since this example is supposed to be a bit smaller, we just use the DataContext directly again.

But, don’t get me wrong, please do it that way, if you want to. It’s totally fine if you want to extend this example. I would recommend doing so, because it’s a great exercise, hence a great way to learn.

Anyways, let’s move on with the IFightService interface.

We only need one method. This method returns a ServiceResponse with an AttackResultDto, we call it WeaponAttack() and pass a WeaponAttackDto as request.

using System.Threading.Tasks;
using dotnet_rpg.Dtos.Fight;
using dotnet_rpg.Models;

namespace dotnet_rpg.Services.FightService
{
    public interface IFightService
    {
         Task<ServiceResponse<AttackResultDto>> WeaponAttack(WeaponAttackDto request);
    }
}

Alright, let’s use the automatic implementation of the interface in the FightService real quick, add the async keyword and then we jump to the FightController before we bring the WeaponAttack() method to life.

public async Task<ServiceResponse<AttackResultDto>> WeaponAttack(WeaponAttackDto request)
{
    throw new NotImplementedException();
}

The implementation of the FightController is straightforward.

Similar to the other controllers we have a public async method returning a Task with an IActionResult. The method is called WeaponAttack() and receives a WeaponAttackDto as request. In the body, we return the result of the awaited _fightService.WeaponAttack() method. Last but not least, don’t forget the [HttpPost] attribute with ”Weapon” for the route. Done.

[HttpPost("Weapon")]
public async Task<IActionResult> WeaponAttack(WeaponAttackDto request)
{
    return Ok(await _fightService.WeaponAttack(request));
}

Now we get to the implementation of the WeaponAttack() method of the FightService.

We already did it before, we start with initializing the ServiceResponse, create a try/catch block and send a failing response back in case of an exception.

public async Task<ServiceResponse<AttackResultDto>> WeaponAttack(WeaponAttackDto request)
{
    ServiceResponse<AttackResultDto> response = new ServiceResponse<AttackResultDto>();
    try
    {
    }
    catch (Exception ex)
    {
        response.Success = false;
        response.Message = ex.Message;
    }
    return response;
}

Now, we need the Characters. That’s what I was talking about when I mentioned the sidenote. You could use the CharacterService to receive the attacker or access the _context.Characters directly, only include the Weapon and, of course, find the one Character whose Id matches the request.AttackerId.

Regarding the opponent, we don’t have to include anything, we just need the one Character with the matching request.OpponentId. Be careful, if you want to use the CharacterService here. If the opponent is not a character of the authenticated user, it won’t work, because the GetCharacterById() function only gives you the RPG characters that are related to the user. So, you would have to write another method that doesn’t care about that relation.

Character attacker = await _context.Characters
    .Include(c => c.Weapon)
    .FirstOrDefaultAsync(c => c.Id == request.AttackerId);
Character opponent = await _context.Characters
    .FirstOrDefaultAsync(c => c.Id == request.OpponentId);

We’ve got the fighting characters, great. Now comes the fun part, we calculate the damage. Again, feel free to be creative and use your own formula.

My ingenious formula takes the Damage of the Weapon and adds a random value between 0 and the Strength of the attacker. After that, a random value between 0 and the Defense of the opponent will be subtracted from the damage value. Crazy, huh?

If the damage is above 0 - yes, it could be below if the attacker is not very strong or the opponent has a tremendous armor - we subtract the damage from the HitPoints of the opponent.

And if the HitPoints are below or equal 0, we could return a Message like $"{opponent.Name} has been defeated!";.

int damage = attacker.Weapon.Damage + (new Random().Next(attacker.Strength));
damage -= new Random().Next(opponent.Defense);
if (damage > 0)
    opponent.HitPoints -= (int)damage;
if (opponent.HitPoints <= 0)
    response.Message = $"{opponent.Name} has been defeated!";

After that, we have to make sure to Update() the opponent in the database and also save these changes with SaveChangesAsync().

_context.Characters.Update(opponent);
await _context.SaveChangesAsync();

Finally, we write the response.Data. We simply set the Name and the HitPoints of the attacker and the opponent as well as the damage.

response.Data = new AttackResultDto
{
    Attacker = attacker.Name,
    AttackerHP = attacker.HitPoints,
    Opponent = opponent.Name,
    OpponentHP = opponent.HitPoints,
    Damage = damage
};

That’s it.

public async Task<ServiceResponse<AttackResultDto>> WeaponAttack(WeaponAttackDto request)
{
    ServiceResponse<AttackResultDto> response = new ServiceResponse<AttackResultDto>();
    try
    {
        Character attacker = await _context.Characters
            .Include(c => c.Weapon)
            .FirstOrDefaultAsync(c => c.Id == request.AttackerId);
        Character opponent = await _context.Characters
            .FirstOrDefaultAsync(c => c.Id == request.OpponentId);
        int damage = attacker.Weapon.Damage + (new Random().Next(attacker.Strength));
        damage -= new Random().Next(opponent.Defense);
        if (damage > 0)
            opponent.HitPoints -= (int)damage;
        if (opponent.HitPoints <= 0)
            response.Message = $"{opponent.Name} has been defeated!";
        _context.Characters.Update(opponent);
        await _context.SaveChangesAsync();
        response.Data = new AttackResultDto
        {
            Attacker = attacker.Name,
            AttackerHP = attacker.HitPoints,
            Opponent = opponent.Name,
            OpponentHP = opponent.HitPoints,
            Damage = damage
        };
    }
    catch (Exception ex)
    {
        response.Success = false;
        response.Message = ex.Message;
    }
    return response;
}

To test this, we’ve got Frodo and Raistlin using the Master Sword and a Crystal Wand.

You see, Frodo has better values, but maybe Raistlin has better chances to win throwing some fireballs later.

In Postman we use the URL http://localhost:5000/fight/weapon with POST as the HTTP method. The body consists of the attackerId and the opponentId.

{
    "attackerid" : 5,
    "opponentid" : 4
}

Make sure you have started the application with dotnet watch run and then let’s attack!

{
    "data": {
        "attacker": "Frodo",
        "opponent": "Raistlin",
        "attackerHP": 100,
        "opponentHP": 71,
        "damage": 29
    },
    "success": true,
    "message": null
}

It’s pretty obvious, Frodo is stronger.

If we let Raistlin attack by switching the Ids, we see that the Crystal Wand can’t do much.

{
    "data": {
        "attacker": "Raistlin",
        "opponent": "Frodo",
        "attackerHP": 71,
        "opponentHP": 97,
        "damage": 3
    },
    "success": true,
    "message": null
}

If we let Frodo attack a couple more times, we see that Raistlin is defeated.

{
    "data": {
        "attacker": "Frodo",
        "opponent": "Raistlin",
        "attackerHP": 97,
        "opponentHP": -18,
        "damage": 31
    },
    "success": true,
    "message": "Raistlin has been defeated!"
}

Alright, that was fun! Let’s implement “The Return of the Mage” now by using some skill attacks.

Attack with Skills

First, we add a new DTO called SkillAttackDto with three int members, the AttackerId, the OpponentId and this time also the SkillId. Since a Character can have multiple skills, we want to specify which skill should be used for the attack.

namespace dotnet_rpg.Dtos.Fight
{
    public class SkillAttackDto
    {
        public int AttackerId { get; set; }
        public int OpponentId { get; set; }
        public int SkillId { get; set; }
    }
}

Then we need a new method, of course. In the IFightService interface we add the method SkillAttack() with the SkillAttackDto as request this time.

Task<ServiceResponse<AttackResultDto>> SkillAttack(SkillAttackDto request);

We’ll cover the FightService in a second. Let’s deal with the FightController instead real quick. You already know it. We can just copy the WeaponAttack() method and make a few little changes.

The method is called SkillAttack(), of course, again with the SkillAttackDto as request, we call the corresponding method of the _fightService and change the route to ”Skill”.

[HttpPost("Skill")]
public async Task<IActionResult> SkillAttack(SkillAttackDto request)
{
    return Ok(await _fightService.SkillAttack(request));
}

Regarding the FightService we can copy the WeaponAttack() method as well and make some changes to the new method. First the name and request type again, of course.

Receiving the attacker looks a bit different now. Instead of including the Weapon, we include the CharacterSkills and then the Skill of each CharacterSkill. Again, here’s an opportunity to use the CharacterService. Receiving the opponent stays the same.

Character attacker = await _context.Characters
    .Include(c => c.CharacterSkills).ThenInclude(cs => cs.Skill)
    .FirstOrDefaultAsync(c => c.Id == request.AttackerId);
Character opponent = await _context.Characters
    .FirstOrDefaultAsync(c => c.Id == request.OpponentId);

Now comes something new, we have to get the correct Skill. Since we included the skills of the RPG character, we don’t access the skills via the _context, we just look if the attacker really has that specific skill.

We initialize a new CharacterSkill object and look through the attacker.CharacterSkills to find the one where the Skill.Id of the CharacterSkill equals the request.SkillId.

If we don’t find one, meaning the characterSkill object is null, because the user requested a wrong SkillId, we return a failing response with a message like {attacker.Name} doesn't know that skill..

CharacterSkill characterSkill =
    attacker.CharacterSkills.FirstOrDefault(cs => cs.Skill.Id == request.SkillId);
if (characterSkill == null)
{
    response.Success = false;
    response.Message = $"{attacker.Name} doesn't know that skill.";
    return response;
}

Regarding the damage we go really crazy. We take the same formula but use characterSkill.Skill.Damage, of course, and replace the Strength with the Intelligence of the attacker.

int damage = characterSkill.Skill.Damage + (new Random().Next(attacker.Intelligence));
damage -= new Random().Next(opponent.Defense);
if (damage > 0)
    opponent.HitPoints -= (int)damage;
if (opponent.HitPoints <= 0)
    response.Message = $"{opponent.Name} has been defeated!";

And that’s already it.

public async Task<ServiceResponse<AttackResultDto>> SkillAttack(SkillAttackDto request)
{
    ServiceResponse<AttackResultDto> response = new ServiceResponse<AttackResultDto>();
    try
    {
        Character attacker = await _context.Characters
            .Include(c => c.CharacterSkills).ThenInclude(cs => cs.Skill)
            .FirstOrDefaultAsync(c => c.Id == request.AttackerId);
        Character opponent = await _context.Characters
            .FirstOrDefaultAsync(c => c.Id == request.OpponentId);

        CharacterSkill characterSkill =
            attacker.CharacterSkills.FirstOrDefault(cs => cs.Skill.Id == request.SkillId);
        if (characterSkill == null)
        {
            response.Success = false;
            response.Message = $"{attacker.Name} doesn't know that skill.";
            return response;
        }

        int damage = characterSkill.Skill.Damage + (new Random().Next(attacker.Intelligence));
        damage -= new Random().Next(opponent.Defense);

        if (damage > 0)
            opponent.HitPoints -= (int)damage;

        if (opponent.HitPoints <= 0)
            response.Message = $"{opponent.Name} has been defeated!";

        _context.Characters.Update(opponent);
        await _context.SaveChangesAsync();

        response.Data = new AttackResultDto
        {
            Attacker = attacker.Name,
            AttackerHP = attacker.HitPoints,
            Opponent = opponent.Name,
            OpponentHP = opponent.HitPoints,
            Damage = damage
        };
    }
    catch (Exception ex)
    {
        response.Success = false;
        response.Message = ex.Message;
    }
    return response;
}

Before we test this, make sure to reset the hit points of our opponents.

In Postman we use the URL http://localhost:5000/fight/skill this time and add the skillId to the request.

{
    "attackerid" : 5,
    "opponentid" : 4,
    "skillid" : 1
}

When we use a skill the character does not have, we should get our proper error message like Frodo doesn’t know that skill.

{
    "data": null,
    "success": false,
    "message": "Frodo doesn't know that skill."
}

But what happens if Frodo uses the skill Frenzy?

{
    "attackerid" : 5,
    "opponentid" : 4,
    "skillid" : 2
}

He still makes good damage!

{
    "data": {
        "attacker": "Frodo",
        "opponent": "Raistlin",
        "attackerHP": 100,
        "opponentHP": 77,
        "damage": 23
    },
    "success": true,
    "message": null
}

Let’s fight back with Raistlin and his fireballs or even with the mighty Blizzard!

{
    "attackerid" : 4,
    "opponentid" : 5,
    "skillid" : 3
}

{
    "data": {
        "attacker": "Raistlin",
        "opponent": "Frodo",
        "attackerHP": 77,
        "opponentHP": -16,
        "damage": 51
    },
    "success": true,
    "message": "Frodo has been defeated!"
}

That’s what I call a fight! The Blizzard makes a lot of damage and Frodo has been defeated.

Okay, but instead of doing these attacks manually, let’s implement an automatic fight next.

That's it for the 12th part of this tutorial series. I hope it was useful for you. To get notified for the next part, simply follow me here on dev.to or subscribe to my newsletter. You'll be the first to know.

See you next time!

Take care.

Next up: More Than Just CRUD with .NET Core 3.1 - Part 2

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.

Many-To-Many Relationship with Entity Framework Core

Patrick God — Tue, 31 Mar 2020 06:28:41 +0000

Advanced Relationships with Entity Framework Core (continued)

Many-To-Many Relation with Skills

Implementing many-to-many relations with Entity Framework Core looks a bit different than implementing the other ones.

In our role-playing game example, we add a bunch of skills, that will be available to all characters. This means, there is no upgrading of one specific skill for a character. There’s just a pool of skills that every character can choose from. So, in general, even a knight could throw a fireball and a mage can smash his opponent in a frenzy.

The first thing to do is adding the Skill model, of course.

We create a new C# class and add the properties Id, Name and Damage.



public class Skill
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Damage { get; set; }
}

Notice, that we don’t add a list of type Character here. We would do that if we wanted to implement a one-to-many relation, but for a many-to-many relationship, we need a special implementation - and that would be a joining table.

Entity Framework Core is currently not able to create a joining table by itself. So we have to add one manually and tell Entity Framework how to join the two entities Skill and Character.

Let’s add the model for this entity first. We create a new C# class and call it CharacterSkill. To join skills and characters now, we have to add them as properties. So, we add a Character and a Skill.

Additionally, we need a primary key for this entity. This will be a composite key of the Skill and the Character. To be able to do that, by convention we add a property CharacterId for the Character, and a property SkillId for the Skill.



public class CharacterSkill
{
    public int CharacterId { get; set; }
    public Character Character { get; set; }
    public int SkillId { get; set; }
    public Skill Skill { get; set; }
}

But that’s not the whole magic. We still have to tell Entity Framework Core that we want to use these two Ids as a composite primary key. We do that with the help of the Fluent API.

We’re switching our focus to the DataContext class. First, we add the new DbSet properties Skills and CharacterSkills.



public DbSet<Skill> Skills { get; set; }
public DbSet<CharacterSkill> CharacterSkills { get; set; }

After that we have to add something new. We override the method OnModelCreating(). This method takes a ModelBuilder argument, which “defines the shape of your entities, the relationships between them and how they map to the database”. Exactly what we need.

The only thing we have to configure here is the composite key of the CharacterSkill entity which consists of the CharacterId and the SkillId. We do that with modelBuilder.Entity<CharacterSkill>().HasKey(cs => new { cs.CharacterId, cs.SkillId });.



protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<CharacterSkill>()
        .HasKey(cs => new { cs.CharacterId, cs.SkillId });
}

That’s it. Thanks to using the naming conventions for the CharacterId and the SkillId we don’t have to configure anything else. Otherwise, we would have to use the Fluent API to configure the relationship between characters and skills with methods like HasOne() and WithMany(). But Entity Framework Core will get this and we can see the correct implementation in a minute in the migration files.

There’s one last thing we have to do and that is adding the CharacterSkill list to the Character and the Skill models.

So, in both C# classes, we add a new property CharacterSkills of type List<CharacterSkill>.



public class Skill
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Damage { get; set; }
    public List<CharacterSkill> CharacterSkills { get; set; }
}



public class Character
{
    public int Id { get; set; }
    public string Name { get; set; } = "Frodo";
    public int HitPoints { get; set; } = 100;
    public int Strength { get; set; } = 10;
    public int Defense { get; set; } = 10;
    public int Intelligence { get; set; } = 10;
    public RpgClass Class { get; set; } = RpgClass.Knight;
    public User User { get; set; }
    public Weapon Weapon { get; set; }
    public List<CharacterSkill> CharacterSkills { get; set; }
}

Alright. When everything is saved, we’re ready to run the migration.

First, we add the new migration with dotnet ef migrations add Skill.

In the created migration file you can see that two new tables will be generated for us, Skills and CharacterSkills.

In the migration design file, a bit further down, you can now see the configuration of the relationship between the joining entity CharacterSkill and the entities Character and Skill.



modelBuilder.Entity("dotnet_rpg.Models.CharacterSkill", b =>
    {
        b.HasOne("dotnet_rpg.Models.Character", "Character")
            .WithMany("CharacterSkills")
            .HasForeignKey("CharacterId")
            .OnDelete(DeleteBehavior.Cascade)
            .IsRequired();
        b.HasOne("dotnet_rpg.Models.Skill", "Skill")
            .WithMany("CharacterSkills")
            .HasForeignKey("SkillId")
            .OnDelete(DeleteBehavior.Cascade)
            .IsRequired();
    });

Again, thanks to using the naming conventions for the Id properties, we don’t have to do this manually.

It’s time to add this migration to the database with dotnet ef database update.

As soon as the update is done, you can refresh the database in SQL Server Management Studio and see the new tables Skills and CharacterSkills with the proper keys.

Great! It’s time to fill these tables with some content.

Add Skills to RPG Characters

Adding new skills to the pool of skills in the database would work pretty straight forward. We need a service, an interface, the controller and so on. I’d say, we focus more on adding the relation between RPG characters and those skills.

So, instead of adding the service for the skills, let’s add some skills manually in the database with SQL Server Management Studio.

Simply right-click the Skills table and select “Edit Top 200 Rows”.

Now we can add some skills like Fireball, Frenzy or Blizzard.

Great. Now we can concentrate on the relations. I can already spoiler, that we will need some DTOs. Let’s create a new folder CharacterSkill and add the new C# class AddCharacterSkillDto with the properties CharacterId and SkillId.



namespace dotnet_rpg.Dtos.CharacterSkill
{
    public class AddCharacterSkillDto
    {
        public int CharacterId { get; set; }
        public int SkillId { get; set; }
    }
}

Next, we create the folder Skill and create the DTO GetSkillDto, because we only need that one to display the skills of a character. The properties we need are Name and Damage.



namespace dotnet_rpg.Dtos.Skill
{
    public class GetSkillDto
    {
        public string Name { get; set; }
        public int Damage { get; set; }
    }
}

After that, we add one more property to the GetCharacterDto and that would be the Skills of type List<GetSkillsDto>.



public class GetCharacterDto
{
    public int Id { get; set; }
    public string Name { get; set; } = "Frodo";
    public int HitPoints { get; set; } = 100;
    public int Strength { get; set; } = 10;
    public int Defense { get; set; } = 10;
    public int Intelligence { get; set; } = 10;
    public RpgClass Class { get; set; } = RpgClass.Knight;
    public GetWeaponDto Weapon { get; set; }
    public List<GetSkillDto> Skills { get; set; }
}

Notice that we already access the skills directly, without using the joining entity CharacterSkill first. You’ll see how we realize that in a minute.

Okay, the DTOs are ready, now we can move on to the service and controller files.

We create a new folder called CharacterSkillService and add a new interface called ICharacterSkillService.

We add only one method that will return a ServiceResponse with a GetCharacterDto because similar to the WeaponService we can see the added skills then. We call the method AddCharacterSkill() and give it an AddCharacterSkillDto as a parameter. Of course, while we’re doing that, we have to add some using directives.



using System.Threading.Tasks;
using dotnet_rpg.Dtos.Character;
using dotnet_rpg.Dtos.CharacterSkill;
using dotnet_rpg.Models;

namespace dotnet_rpg.Services.CharacterSkillService
{
    public interface ICharacterSkillService
    {
        Task<ServiceResponse<GetCharacterDto>> AddCharacterSkill(AddCharacterSkillDto newCharacterSkill);
    }
}

Now we can already create the CharacterSkillService. This service will look pretty similar to the WeaponService. We start by implementing the ICharacterSkillService interface and add the AddCharacterSkill() method automatically and add the async keyword already.



public class CharacterSkillService : ICharacterSkillService
{
    public async Task<ServiceResponse<GetCharacterDto>> AddCharacterSkill(AddCharacterSkillDto newCharacterSkill)
    {
        throw new NotImplementedException();
    }
}

Before we write the actual code of this method, we add the constructor. Similar to the WeaponService we inject the DataContext, the IHttpContextAccessor and the IMapper. We add the using directives, initialize all fields from the parameters and if you want, add the underscore in front of every field.



private readonly DataContext _context;
private readonly IHttpContextAccessor _httpContextAccessor;
private readonly IMapper _mapper;

public CharacterSkillService(DataContext context, IHttpContextAccessor httpContextAccessor, IMapper mapper)
{
    _mapper = mapper;
    _httpContextAccessor = httpContextAccessor;
    _context = context;
}

Now to the AddCharacterSkill() method.

First, we initialize the returning ServiceResponse and build an empty try/catch block.

In case of an exception, we can already set the Success state of the response to false and set the Message to the exception message.



public async Task<ServiceResponse<GetCharacterDto>> AddCharacterSkill(AddCharacterSkillDto newCharacterSkil
{
    ServiceResponse<GetCharacterDto> response = new ServiceResponse<GetCharacterDto>();
    try
    {
    }
    catch (Exception ex)
    {
        response.Success = false;
        response.Message = ex.Message;
    }
    return response;
}

Next would be to receive the correct Character from the database that was given by the CharacterId through the AddCharacterSkillDto.

Again, it’s pretty similar to the WeaponService.

First, we access the Characters from the _context and filter them with the method FirstOrDefaultAsync() by the newCharacterSkill.CharacterId and additionally by the authenticated User. You remember this long line to receive the user id from the claims, right?



Character character = await _context.Characters
    .FirstOrDefaultAsync(c => c.Id == newCharacterSkill.CharacterId &&
    c.User.Id == int.Parse(_httpContextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.NameIdentifier)));

But that’s not all. To receive all skills and also the related Weapon of the user, we have to include them.

We can start with the Weapon. After _context.Characters we add .Include(c => c.Weapon). The skills are getting a bit more interesting. Again we add .Include(), but first we access the CharacterSkills and after that we access the child property Skill of the CharacterSkills with .ThenInclude().

That way, we get every property from the character that is stored in the database.



Character character = await _context.Characters
    .Include(c => c.Weapon)
    .Include(c => c.CharacterSkills).ThenInclude(cs => cs.Skill)
    .FirstOrDefaultAsync(c => c.Id == newCharacterSkill.CharacterId &&
    c.User.Id == int.Parse(_httpContextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.NameIdentifier)));

With that out of the way, we add the usual null-check. So, if the character is null we set the Success state and the Message and return the response.



Character character = await _context.Characters
    .Include(c => c.Weapon)
    .Include(c => c.CharacterSkills).ThenInclude(cs => cs.Skill)
    .FirstOrDefaultAsync(c => c.Id == newCharacterSkill.CharacterId &&
    c.User.Id == int.Parse(_httpContextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.NameIdentifier))

if (character == null)
{
    response.Success = false;
    response.Message = "Character not found.";
    return response;
}

Next is the Skill. With the given SkillId from the newCharacterSkill parameter, we grab the skill from the database.



Skill skill = await _context.Skills
    .FirstOrDefaultAsync(s => s.Id == newCharacterSkill.SkillId);

Similar to the character, if we cannot find the skill with the given SkillId, we set the ServiceResponse and return it.



if (skill == null)
{
    response.Success = false;
    response.Message = "Skill not found.";
    return response;
}

Now we have everything we need to create a new CharacterSkill.

We initialize a new characterSkill object and set the Character and Skill properties of that object to the character and the skill we got from the database before.



CharacterSkill characterSkill = new CharacterSkill
{
    Character = character,
    Skill = skill
};

After that, we add this new CharacterSkill to the database with AddAsync(characterSkill), save all changes to the database and finally set the response.Data to the mapped character.



await _context.CharacterSkills.AddAsync(characterSkill);
await _context.SaveChangesAsync();

response.Data = _mapper.Map<GetCharacterDto>(character);

And that’s the whole AddCharacterSkill() method.



public async Task<ServiceResponse<GetCharacterDto>> AddCharacterSkill(AddCharacterSkillDto newCharacterSkill)
{
    ServiceResponse<GetCharacterDto> response = new ServiceResponse<GetCharacterDto>();
    try
    {
        Character character = await _context.Characters
            .Include(c => c.Weapon)
            .Include(c => c.CharacterSkills).ThenInclude(cs => cs.Skill)
            .FirstOrDefaultAsync(c => c.Id == newCharacterSkill.CharacterId &&
            c.User.Id == int.Parse(_httpContextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.NameIdentifier))
        if (character == null)
        {
            response.Success = false;
            response.Message = "Character not found.";
            return response;
        }
        Skill skill = await _context.Skills
            .FirstOrDefaultAsync(s => s.Id == newCharacterSkill.SkillId);
        if (skill == null)
        {
            response.Success = false;
            response.Message = "Skill not found.";
            return response;
        }
        CharacterSkill characterSkill = new CharacterSkill
        {
            Character = character,
            Skill = skill
        };

        await _context.CharacterSkills.AddAsync(characterSkill);
        await _context.SaveChangesAsync();
        response.Data = _mapper.Map<GetCharacterDto>(character);
    }
    catch (Exception ex)
    {
        response.Success = false;
        response.Message = ex.Message;
    }
    return response;
}

To be able to call the service, we need the CharacterSkillController, so let’s create this new C# file.

As always, we derive from ControllerBase and add the attributes [Route(“[controller]”)], [ApiController] and [Authorize]. We need the user information, hence this controller should only be accessed by authenticated users.



[Authorize]
[ApiController]
[Route("[controller]")]
public class CharacterSkillController : ControllerBase

Then we need a constructor that only injects the ICharacterSkillService.



private readonly ICharacterSkillService _characterSkillService;
public CharacterSkillController(ICharacterSkillService characterSkillService)
{
    _characterSkillService = characterSkillService;
}

And finally we add the public async POST method AddCharacterSkill() with an AddCharacterSkillDto as parameter which is passed to the AddCharacterSkill() method of the _characterSkillService.



[HttpPost]
public async Task<IActionResult> AddCharacterSkill(AddCharacterSkillDto newCharacterSkill)
{
    return Ok(await _characterSkillService.AddCharacterSkill(newCharacterSkill));
}

So far the controller.

Now we register the new service in the Startup.cs file. As almost always, we use services.AddScoped() for that in the ConfigureServices() method.



services.AddScoped<ICharacterSkillService, CharacterSkillService>();

The last thing is a change to the AutoMapperProfile.

The easy part is a new map for the GetSkillDto.



CreateMap<Skill, GetSkillDto>();

Now it’s getting more interesting. I already told you, that we want to access the skills of a character directly, without displaying the joining entity CharacterSkill. We can do that with the help of AutoMapper and the help of the Select() function.

First we utilize the ForMember() function for the <Character, GetCharacterDto>-Map. With this function, we can define a special mapping for a specific member of the mapped type.

In our case, we properly want to set the Skills of the DTO.

To do that, we access the Character object and from that object - hence the function MapFrom() - we grab the CharacterSkills and select the Skill from every CharacterSkill.



CreateMap<Character, GetCharacterDto>()
    .ForMember(dto => dto.Skills, c => c.MapFrom(c => c.CharacterSkills.Select(cs => cs.Skill)));

That’s how we make the jump to the skills directly.

Great! It’s time to test this.

Make sure to have your user logged in and the correct token in place. Then we can use the URL http://localhost:5000/characterskill with the HTTP method POST. The body of the call consists of the characterId and the skillId.



{
    "characterid" : 5,
    "skillid" : 1
}

Executing this call, we get the complete RPG character back with its weapon and the new skill.



{
    "data": {
        "id": 5,
        "name": "Frodo",
        "hitPoints": 200,
        "strength": 10,
        "defense": 10,
        "intelligence": 10,
        "class": 1,
        "weapon": {
            "name": "The Master Sword",
            "damage": 10
        },
        "skills": [
            {
                "name": "Fireball",
                "damage": 30
            }
        ]
    },
    "success": true,
    "message": null
}

When we add another skill, we see the complete array of skills.



{
    "data": {
        "id": 5,
        "name": "Frodo",
        "hitPoints": 200,
        "strength": 10,
        "defense": 10,
        "intelligence": 10,
        "class": 1,
        "weapon": {
            "name": "The Master Sword",
            "damage": 10
        },
        "skills": [
            {
                "name": "Fireball",
                "damage": 30
            },
            {
                "name": "Frenzy",
                "damage": 20
            }
        ]
    },
    "success": true,
    "message": null
}

In the database, you can also see that the joining table is filled with the new IDs.

Perfect! The RPG character is equipped with a weapon and skills.

Feel free to play around with this.

If you want to use the GetCharacterById() method in the CharacterService to see the equipment of any character, make sure to add the Include() method as shown before, meaning include the Weapon as well as the Skills of the CharacterSkills.



public async Task<ServiceResponse<GetCharacterDto>> GetCharacterById(int id)
{
    ServiceResponse<GetCharacterDto> serviceResponse = new ServiceResponse<GetCharacterDto>();
    Character dbCharacter = 
        await _context.Characters
        .Include(c => c.Weapon)
        .Include(c => c.CharacterSkills).ThenInclude(cs => cs.Skill)
        .FirstOrDefaultAsync(c => c.Id == id && c.User.Id == GetUserId());
    serviceResponse.Data = _mapper.Map<GetCharacterDto>(dbCharacter);
    return serviceResponse;
}

When all your RPG characters are set, I guess it’s time to fight!

Summary

Congrats! You implemented all types of relationships into your application.

But that’s not all.

In this chapter, first, you learned how to grab the authenticated user from a web service call and receive proper data based on that user from the database. That way you were able to show every user her own characters.

After that, we covered a one-to-one relationship. An RPG character can now be equipped with one weapon and only that one single weapon.

Regarding the many-to-many relationship, we added skills to our characters together with the necessary joining entity or table CharacterSkills. Characters are allowed to have several skills and skills can have several characters.

Apart from that you created all the necessary services and controllers to add weapons and skills and you learned how to include deeper nested entities and how to define custom mappings with AutoMapper.

In the next chapter, we will go one step further and implement functions to let the RPG characters fight against each other.

That's it for the 11th part of this tutorial series. I hope it was useful for you. To get notified for the next part, simply follow me here on dev.to or subscribe to my newsletter. You'll be the first to know.

See you next time!

Take care.

Next up: More Than Just CRUD with .NET Core 3.1

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.

One-to-One Relationship with Entity Framework Core

Patrick God — Tue, 24 Mar 2020 16:03:42 +0000

Advanced Relationships with Entity Framework Core (continued)

One-To-One Relation with Weapons

Now let’s add a new model to our Web API - the Weapon. The idea behind this is that every Character will only have one Weapon and vice versa.

I know, this is not your typical role-playing game. Usually, you would have several weapons in your inventory and equip one or two, but for this example, your RPG character only gets one weapon and if you want to change it, you have to drop the other.

So, we create a new C# class called Weapon with the properties Id, Name, Damage and the related Character.

namespace dotnet_rpg.Models
{
    public class Weapon
    {
        public int Id { get; set; }

        public string Name { get; set; }

        public int Damage { get; set; }

        public Character Character { get; set; }
    }
}

After that, we have to add another property to the Character class, namely the Weapon. Do you already see how to create a one-to-one relation?

public Weapon Weapon { get; set; }

Since we added a new model we also want to see it as a table in the database. So, we have to add the Weapon class as DbSet to the DataContext.

public DbSet<Weapon> Weapons { get; set; }

Alright, it looks like we already got everything ready for the migration. So, in the terminal we type dotnet ef migrations add Weapon and hit return.

What’s that? We get an error!

The error says:

Okay. So, this means that we have to define an explicit foreign key property. With the help of the foreign key, the database knows where to look for the related entity.

In our example, we want the Weapon to be the dependent side of the relationship. There must be a Character for this Weapon. It cannot exist without one. The Character on the other hand can exist without a Weapon.

We realize that by adding another property to the Weapon class, and that would be the property CharacterId as an int. With the help of that convention - using the C# class name and the text “Id” - Entity Framework knows that this is the corresponding foreign key for the Character property. That’s it already.

public int CharacterId { get; set; }

Let’s give it another try and add the migration again with dotnet ef migrations add Weapon.

This time everything should work just fine.

In the Up() method of the migration file, we see the creation of the new Weapons table and the definition of the foreign key constraint.

protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.CreateTable(
        name: "Weapons",
        columns: table => new
        {
            Id = table.Column<int>(nullable: false)
                .Annotation("SqlServer:Identity", "1, 1"),
            Name = table.Column<string>(nullable: true),
            Damage = table.Column<int>(nullable: false),
            CharacterId = table.Column<int>(nullable: false)
        },
        constraints: table =>
        {
            table.PrimaryKey("PK_Weapons", x => x.Id);
            table.ForeignKey(
                name: "FK_Weapons_Characters_CharacterId",
                column: x => x.CharacterId,
                principalTable: "Characters",
                principalColumn: "Id",
                onDelete: ReferentialAction.Cascade);
        });
    migrationBuilder.CreateIndex(
        name: "IX_Weapons_CharacterId",
        table: "Weapons",
        column: "CharacterId",
        unique: true);
}

The Down() method simply drops the Weapons table.

protected override void Down(MigrationBuilder migrationBuilder)
{
    migrationBuilder.DropTable(
        name: "Weapons");
}

In the migration design file, we also see the definition of the relation between Character and Weapon. With the methods HasOne() and WithOne() Entity Framework defines the one-to-one relation. Additionally, you can see the definition of the foreign key and also what will happen if a Character gets removed. With OnDelete(DeleteBehavior.Cascade) the Weapon will be removed together with the Character.

modelBuilder.Entity("dotnet_rpg.Models.Weapon", b =>
                {
                    b.HasOne("dotnet_rpg.Models.Character", "Character")
                        .WithOne("Weapon")
                        .HasForeignKey("dotnet_rpg.Models.Weapon", "CharacterId")
                        .OnDelete(DeleteBehavior.Cascade)
                        .IsRequired();

I’d say we run this migration now with dotnet ef database update.

Now we can happily see the new table in the database with the SQL Server Management Studio.

Perfect. We got the Weapon entity, now it’s time to add some weapons with our Web API.

Add Weapons to RPG Characters

We start with creating a new folder for our WeaponService and then create the interface IWeaponService. This interface only gets one method called AddWeapon(), returning a GetCharacterDto and taking an AddWeaponDto.

public interface IWeaponService
{
     Task<ServiceResponse<GetCharacterDto>> AddWeapon(AddWeaponDto newWeapon);
}

As you can see we have to add some using directives and we have to create the new DTO.

For that, we create a new Weapon folder in the Dtos folder and create the C# class AddWeaponDto with the properties Name, Damage and CharacterId.

namespace dotnet_rpg.Dtos.Weapon
{
    public class AddWeaponDto
    {
        public string Name { get; set; }

        public int Damage { get; set; }

        public int CharacterId { get; set; }
    }
}

Now we should be able to add the last missing using directive in the IWeaponService interface.

Next, we create the WeaponService implementation class and implement the corresponding interface and add the async keyword to the AddWeapon() method.

namespace dotnet_rpg.Services.WeaponService
{
    public class WeaponService : IWeaponService
    {
        public async Task<ServiceResponse<GetCharacterDto>> AddWeapon(AddWeaponDto newWeapon)
        {
            throw new System.NotImplementedException();
        }
    }
}

We also need a constructor injecting the DataContext, the IHttpContextAccessor to get the currently authorized user and an IMapper. We need the user to verify the given CharacterId later.

private readonly DataContext _context;
private readonly IHttpContextAccessor _httpContextAccessor;
private readonly IMapper _mapper;

public WeaponService(DataContext context, IHttpContextAccessor httpContextAccessor, IMapper mapper)
{
    _mapper = mapper;
    _httpContextAccessor = httpContextAccessor;
    _context = context;
}

Regarding the implementation of the AddWeapon() method we first initialize the ServiceResponse, return this response and already create a try/catch block where we set the proper values in the case of an exception.

public async Task<ServiceResponse<GetCharacterDto>> AddWeapon(AddWeaponDto newWeapon)
{
    ServiceResponse<GetCharacterDto> response = new ServiceResponse<GetCharacterDto>();
    try
    {
    }
    catch (Exception ex)
    {
        response.Success = false;
        response.Message = ex.Message;

    }
    return response;
}

Now for the try block, we first get the correct Character from the database. We access the Characters from the _context, find the first entity with the given CharacterId and also the correct User so that we know this character really belongs to the currently authorized user.

Just to recap, we get the Id of the current user by accessing the NameIdentifier claims value from the JSON web token.

Character character = await _context.Characters
    .FirstOrDefaultAsync(c => c.Id == newWeapon.CharacterId &&
    c.User.Id == int.Parse(_httpContextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.NameIdentifier)));

Alright. When the character is null, something is wrong and we return a failing response.

if (character == null)
{
    response.Success = false;
    response.Message = "Character not found.";
    return response;
}

However, if we got the proper character, we can create a new Weapon instance, with the given Name and Damage value and also set the Character property of this new Weapon instance to the character object we got from the database.

By the way, we could have added a new mapping from the AddWeaponDto to the Weapon type, or we just set these two properties manually here.

Weapon weapon = new Weapon
{
    Name = newWeapon.Name,
    Damage = newWeapon.Damage,
    Character = character
};

After that, we add this new weapon to the database, save the changes and return the character.

await _context.Weapons.AddAsync(weapon);
await _context.SaveChangesAsync();

response.Data = _mapper.Map<GetCharacterDto>(character);

The last piece of the puzzle is a WeaponController. So, let’s create one.

It derives from ControllerBase and we also have to add the attributes [Route("[controller]")], [ApiController] and [Authorize] together with the corresponding using directives.

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

namespace dotnet_rpg.Controllers
{
    [Authorize]
    [ApiController]
    [Route("[controller]")]
    public class WeaponController : ControllerBase
    {

    }
}

Then we need a constructor that is injecting the IWeaponService. As always we can initialize this field from the parameter.

private readonly IWeaponService _weaponService;
public WeaponController(IWeaponService weaponService)
{
    _weaponService = weaponService;
}

After that, we only need one POST method, which is AddWeapon() with an AddWeaponDto as a parameter and returning the result of the AddWeapon() method of the _weaponService.

[HttpPost]
public async Task<IActionResult> AddWeapon(AddWeaponDto newWeapon)
{
    return Ok(await _weaponService.AddWeapon(newWeapon));
}

Did we forget something?

Yes. We have to register the WeaponService in the Startup.cs.

In the ConfigureServices() method we can add this new service with services.AddScoped<IWeaponService, WeaponService>();.

Now that was a lot. Let’s test this with Postman.

Make sure to log in a user first to get a valid token.

After that we try to create a new weapon with the URL http://localhost:5000/weapon, the HTTP method is POST and don’t forget the Authorization key in the header with the proper bearer token.

Regarding the body, make sure to use a cool name for your weapon and a correct characterId for your logged-in user.

{
    "name" : "The Master Sword",
    "damage" : 10,
    "characterId" : 5
}

Running the call results in a successful response. But it’s not very satisfying. We don’t see the weapon of the character. Well, of course, we don’t see it, because we haven’t added the weapon to the GetCharacterDto.

But let’s have a look at the weapons table in the SQL Server Management Studio.

There it is, the beautiful Master Sword.

What happens now, if we try to add another weapon to the same character?

{
    "data": null,
    "success": false,
    "message": "An error occurred while updating the entries. See the inner exception for details."
}

We get an exception! Not very helpful. But when we have a closer look at the Terminal in Visual Studio Code, we can see the following error message.

Microsoft.Data.SqlClient.SqlException (0x80131904): Cannot insert duplicate key row in object 'dbo.Weapons' with unique index 'IX_Weapons_CharacterId'.

And it even tells us the Id of the character. So the one-to-one relation works just fine. To add another weapon, we first have to remove the Master Sword from the database table.

But first, let’s fix the GetCharacterDto. This can be done real quick.

We create a new GetWeaponDto class that only consists of the Name and the Damage of the Weapon. No need for an Id or the Character here.

namespace dotnet_rpg.Dtos.Weapon
{
    public class GetWeaponDto
    {
        public string Name { get; set; }
        public int Damage { get; set; }
    }
}

Then we add the Weapon property of type GetWeaponDto to the GetCharacterDto.

public class GetCharacterDto
{
    public int Id { get; set; }
    public string Name { get; set; } = "Frodo";
    public int HitPoints { get; set; } = 100;
    public int Strength { get; set; } = 10;
    public int Defense { get; set; } = 10;
    public int Intelligence { get; set; } = 10;
    public RpgClass Class { get; set; } = RpgClass.Knight;
    public GetWeaponDto Weapon { get; set; }
}

And finally, we create a new map in the AutoMapperProfile - from Weapon to GetWeaponDto.

public AutoMapperProfile()
{
    CreateMap<Character, GetCharacterDto>();
    CreateMap<AddCharacterDto, Character>();
    CreateMap<Weapon, GetWeaponDto>();
}

That’s it. When we now delete the weapon of our character in the database first and then create it again with Postman, we get the complete character back - with the related weapon.

{
    "data": {
        "id": 5,
        "name": "Frodo",
        "hitPoints": 200,
        "strength": 10,
        "defense": 10,
        "intelligence": 10,
        "class": 1,
        "weapon": {
            "name": "The Master Sword",
            "damage": 10
        }
    },
    "success": true,
    "message": null
}

That's it for the 10th part of this tutorial series. I hope it was useful for you. To get notified for the next part, simply follow me here on dev.to or subscribe to my newsletter. You'll be the first to know.

See you next time!

Take care.

Next up: Many-to-Many Relationship with Entity Framework Core

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.

Advanced Relationships with Entity Framework Core

Patrick God — Wed, 18 Mar 2020 16:39:48 +0000

Advanced Relationships with Entity Framework Core

Introduction

Welcome to the Advanced Relationships with Entity Framework Core section.

So far, we have created a one-to-many relation between the User entity and the Character entity.

Users can have several characters but not the other way around. An RPG character can only have one user.

That way we can make sure that users only see the characters they have created. Pretty obvious, but it’s still important to make this clear.

Apart from one-to-many relations there are also one-to-one and many-to-many relations available in relational databases. So we still got two cases to cover.

We will do that by adding weapons and skills to our example application.

Weapons will be unique, and an RPG character will only be able to have one single weapon. Interesting concept, I know, but it works for our example.

The skills, on the other hand, will be available to all characters and they can have as many as they like. So, yeah, even a knight might be able to throw fireballs. Why not?

But before we add new models and new relations to our application, let’s take care of the relation between users and RPG characters. We are able to get related RPG characters of the user, but there are still some operations missing.

Proper User-Character Relation

So far, when a new character is generated, it doesn’t have a connection to the user. To fix that we have to know who the current user is when we create a new RPG character.

Actually, we need to know the current user for any operation. Think about updating or deleting a character.

It looks like we have to pass the userId from the CharacterController to every single method of the CharacterService.

Well, there’s a better way.

Instead of passing the current user from the controller to the service, we can inject the IHttpContextAccessor in the CharacterService and access the current user from there.

We could have done this before, sorry that you have to change the GetAllCharacters() method again, but that’s how we learn, right?

First, we have to register the IHttpContextAccessor in the Startup class. This time, we register it as a singleton!

services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();

And we add the Microsoft.AspNetCore.Http library.

Then we go to CharacterService and inject the IHttpContextAccessor in the constructor.

private readonly IHttpContextAccessor _httpContextAccessor;

public CharacterService(IMapper mapper, DataContext context, IHttpContextAccessor httpContextAccessor)
{
    _httpContextAccessor = httpContextAccessor;
    _context = context;
    _mapper = mapper;
}

Since we need the Id of the authenticated user quite often, let’s write a method for that and call it GetUserId().

We access the user via _httpContextAccessor.HttpContext.User and this time let’s use the method FindFirstValue() to get the value we’re looking for. And don’t forget to parse the result to an int.

private int GetUserId() => int.Parse(_httpContextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.NameIdentifier));

Now we can use this method in GetAllCharacters(). Let’s also remove the userId parameter.

public async Task<ServiceResponse<List<GetCharacterDto>>> GetAllCharacters()
{
    ServiceResponse<List<GetCharacterDto>> serviceResponse = new ServiceResponse<List<GetCharacterDto>>();
    List<Character> dbCharacters = await _context.Characters.Where(c => c.User.Id == GetUserId()).ToListAsync();
    serviceResponse.Data = dbCharacters.Select(c => _mapper.Map<GetCharacterDto>(c)).ToList();
    return serviceResponse;
}

We also remove the userId parameter in the interface

Task<ServiceResponse<List<GetCharacterDto>>> GetAllCharacters();

The same for the controller. Here we can even remove the line where we were grabbing the user.

[HttpGet("GetAll")]
public async Task<IActionResult> Get()
{
    return Ok(await _characterService.GetAllCharacters());
}

Alright. Let’s test this real quick with Postman and then we modify all the other methods.

The URL and HTTP method stays the same, just make sure to update the bearer token if you get a 401 Unauthorized as a result. Remember, we gave the token an expiration time of one day. So if you had a break, it’s possible that the token already expired.

Anyways, the result should be the same and we get the RPG characters that are related to our user.

Alright, now let’s fix the other methods.

First, we add the current user to a created RPG character.

In the AddCharacter() method, after we map the AddCharacterDto to the Character type, we set the character.User by grabbing the User object from the database with await _context.Users.FirstOrDefaultAsync() and as condition, we want the user with the Id of the authenticated user.

character.User = await _context.Users.FirstOrDefaultAsync(u => u.Id == GetUserId());

We can already test that. The URL of the POST call is http://localhost:5000/character and in the body, I’d like to create a mage called “Raistlin”, this time with different attributes for his intelligence, strength, and defense.

{
    "name":"Raistlin",
    "class": 2,
    "intelligence": 20,
    "strength" : 5,
    "defense" : 5
}

In the database, we can now see that our new mage was created and the UserId was properly set.

We can also see that our second character still has no related user. Let’s just enter the id 1 to fix that.

Another thing we should add is the returning result of the AddCharacter() method. We get all characters back, regardless of the related user. We got three characters back, although only two were related to the authorized user.

To illustrate this, we can create a new user and then a new character with that user.

So we start with the registration in Postman, URL is http://localhost:5000/auth/register. Let’s get really creative with the username.

{
    "username":"testuser",
    "password": "123456"
}

After that, let’s log the user right in to grab the proper token. We use that token now to create a new character.

We can leave the body empty to create our default character Frodo.

As you can see, we get all characters from the database back, although only one character is related to the current user.

{
    "data": [
        {
            "id": 1,
            "name": "Frodo",
            "hitPoints": 200,
            "strength": 20,
            "defense": 10,
            "intelligence": 10,
            "class": 2
        },
        {
            "id": 2,
            "name": "Sam",
            "hitPoints": 100,
            "strength": 10,
            "defense": 10,
            "intelligence": 10,
            "class": 1
        },
        {
            "id": 4,
            "name": "Raistlin",
            "hitPoints": 100,
            "strength": 5,
            "defense": 5,
            "intelligence": 20,
            "class": 2
        },
        {
            "id": 5,
            "name": "Frodo",
            "hitPoints": 100,
            "strength": 10,
            "defense": 10,
            "intelligence": 10,
            "class": 1
        }
    ],
    "success": true,
    "message": null
}

To fix this, we go back to the AddCharacter() method and filter the returning characters with Where(c => c.User.Id == GetUserId()).

public async Task<ServiceResponse<List<GetCharacterDto>>> AddCharacter(AddCharacterDto newCharacter)
{
    ServiceResponse<List<GetCharacterDto>> serviceResponse = new ServiceResponse<List<GetCharacterDto>>();
    Character character = _mapper.Map<Character>(newCharacter);
    character.User = await _context.Users.FirstOrDefaultAsync(u => u.Id == GetUserId());

    await _context.Characters.AddAsync(character);
    await _context.SaveChangesAsync();

    serviceResponse.Data = (_context.Characters.Where(c => c.User.Id == GetUserId()).Select(c => _mapper.Map<GetCharacterDto>(c))).ToList();
    return serviceResponse;
}

When we create another Frodo now, we only get the two Frodos of the current user back.

{
    "data": [
        {
            "id": 5,
            "name": "Frodo",
            "hitPoints": 100,
            "strength": 10,
            "defense": 10,
            "intelligence": 10,
            "class": 1
        },
        {
            "id": 6,
            "name": "Frodo",
            "hitPoints": 100,
            "strength": 10,
            "defense": 10,
            "intelligence": 10,
            "class": 1
        }
    ],
    "success": true,
    "message": null
}

Alright, now the methods UpdateCharacter(), GetCharacterById() and DeleteCharacter() are left.

In essence, we want to check if the current user is allowed to see, delete or update the RPG character with the given id. As always, there are several ways to do this.

Let’s start with the GetCharacterById() method.

We can fix this one real quick by simply adding a second condition to the predicate so that we not only check the Id of the character, but also the Id of the related User.

Character dbCharacter = await _context.Characters.FirstOrDefaultAsync(c => c.Id == id && c.User.Id == GetUserId());

Now we only get our own RPG characters.

If the user is not allowed to see a particular character, the result is null.

Deleting a character works similarly. But let’s make some more changes. First I’d like to use the method FirstOrDefaultAsync() and then we add the second condition c.User.Id == GetUserId().

After that, we check if the resulting character is not null and only then we remove it, save the changes to the database and then only return all characters that belong to the current user. So we add another condition with Where(c => c.User.Id == GetUserId()).

If, however, the character is null we return a failing serviceResponse with a Message like Character not found.

public async Task<ServiceResponse<List<GetCharacterDto>>> DeleteCharacter(int id)
{
    ServiceResponse<List<GetCharacterDto>> serviceResponse = 
        new ServiceResponse<List<GetCharacterDto>>();
    try
    {
        Character character = 
            await _context.Characters.FirstOrDefaultAsync(c => c.Id == id && c.User.Id == GetUserId());
        if (character != null)
        {
            _context.Characters.Remove(character);
            await _context.SaveChangesAsync();
            serviceResponse.Data = (_context.Characters.Where(c => c.User.Id == GetUserId())
                .Select(c => _mapper.Map<GetCharacterDto>(c))).ToList();
        }
        else
        {
            serviceResponse.Success = false;
            serviceResponse.Message = "Character not found.";
        }
    }
    catch (Exception ex)
    {
        serviceResponse.Success = false;
        serviceResponse.Message = ex.Message;
    }
    return serviceResponse;
}

When we now want to delete an RPG character that doesn’t belong to the current user, we get the corresponding error message back.

{
    "data": null,
    "success": false,
    "message": "Character not found."
}

When we delete a correct character, we get the rest back.

{
    "data": [
        {
            "id": 5,
            "name": "Frodo",
            "hitPoints": 100,
            "strength": 10,
            "defense": 10,
            "intelligence": 10,
            "class": 1
        }
    ],
    "success": true,
    "message": null
}

Last but not least is the UpdateCharacter() method. In essence, we could add the exact same condition as before.

But I want to emphasize a certain behavior of Entity Framework here.

Include Entities with Entity Framework

Instead of adding another condition, we could also check the UserId of the character after receiving it from the database, right? Let’s try that.

We add an if-condition with character.User.Id == GetUserId(), and regarding the else case we can return the same serviceResponse we also returned in the DeleteCharacter() method.

public async Task<ServiceResponse<GetCharacterDto>> UpdateCharacter(UpdateCharacterDto updatedCharacter)
{
    ServiceResponse<GetCharacterDto> serviceResponse = new ServiceResponse<GetCharacterDto>();
    try
    {
        Character character = await _context.Characters.FirstOrDefaultAsync(c => c.Id == updatedCharacter.Id);
        if (character.User.Id == GetUserId())
        {
            character.Name = updatedCharacter.Name;
            character.Class = updatedCharacter.Class;
            character.Defense = updatedCharacter.Defense;
            character.HitPoints = updatedCharacter.HitPoints;
            character.Intelligence = updatedCharacter.Intelligence;
            character.Strength = updatedCharacter.Strength;
            _context.Characters.Update(character);
            await _context.SaveChangesAsync();
            serviceResponse.Data = _mapper.Map<GetCharacterDto>(character);
        }
        else
        {
            serviceResponse.Success = false;
            serviceResponse.Message = "Character not found.";
        }
    }
    catch (Exception ex)
    {
        serviceResponse.Success = false;
        serviceResponse.Message = ex.Message;
    }
    return serviceResponse;
}

Back to Postman, we get a single character first and then grab the result to overwrite the character with similar values.

Remember to use the PUT HTTP method and the URL http://localhost:5000/character without an Id.

What do we get? A NullReferenceException.

{
    "data": null,
    "success": false,
    "message": "Object reference not set to an instance of an object."
}

But why? Let’s debug our Web API for that. We stop the current process with Ctrl + C, set a breakpoint into the UpdateCharacter() method and then start the debugger.

When the debugger is running, we send another request with Postman and then step through the method.

After receiving the character from the database, under “Variables” we can see that the User object of the character is indeed null.

Entity Framework did not include the related object to the character. It works when we add a second condition to the FirstOrDefaultAsync() method because the DbContext is still available there. But after that, we only got the RPG character with no relations.

Of course, we can tell Entity Framework to act differently. After _context.Characters we add the Include() function and the small lambda expression to include the User property.

Character character = await _context.Characters.Include(c => c.User).FirstOrDefaultAsync(c => c.Id == updatedCharacter.Id);

When we save that, restart the debugger and send the request again, we finally get the User with all its properties, so that we can check the Id.

And we also get the updated RPG character.

{
    "data": {
        "id": 5,
        "name": "Frodo",
        "hitPoints": 200,
        "strength": 10,
        "defense": 10,
        "intelligence": 10,
        "class": 1
    },
    "success": true,
    "message": null
}

Great. So keep that in mind, if you want to access related objects. You might have to include them first.

That's it for the 9th part of this tutorial series. I hope it was useful for you. To get notified for the next part, simply follow me here on dev.to or subscribe to my newsletter. You'll be the first to know.

See you next time!

Take care.

Next up: One-to-One Relationship with Entity Framework Core

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.

Authentication with JSON Web Tokens in .NET Core 3.1

Patrick God — Thu, 12 Mar 2020 16:12:15 +0000

Authentication (continued)

Token Authentication with JSON Web Tokens

The idea behind token authentication is simple.

At this stage of our application, the user can log in with her username and password. We verify the credentials and tell the user that the password is correct.

But if the user wants to call a function, where she needs to be authenticated, she would have to send the credentials again. That’s because the web service is stateless.

This means, we never know who sent a request. Unless we get some credentials with the request.

Instead of entering the credentials every single time with every request, we could store the username and password on the local or session storage of the browser and grab the information from there. But that’s highly insecure because everybody who has access to your computer could have a glance at your password.

That’s where tokens come in.

A token is nothing more than a long string that stores information - or claims - of the user. These claims do not consist of the password, but it could tell the server who the user is and what kind of rights the user might have.

The token is generated with a private key only the server knows. So it’s hard to fake such a token. And we can give that token an expiration date. So, even if someone would be able to steal your token, chances are that the token is invalid as soon as this certain someone tries to use it.

Since this token doesn’t consist of critical information in plain text, we can store it in the browser and automatically send it to the web service with every request.

The service then knows who the user is and may even send a new token back for your next request.

On the website jwt.io, we’re able to have a look at a JSON web token and even how the information is stored in it.

You see the header with the used algorithm and the payload with claims like the name of the user, for instance.

Okay, let’s use JSON web tokens now for our Web API.

JSON Web Tokens (JWT) preparations

There are some things we have to do first before we write the actual code.

We start with the appsettings.json. Here we enter the security key for the JWT authentication. Below the ConnectionStrings section, we can create a new section AppSettings and just enter a new key called Token and set any kind of string as value. For instance, my top secret key would be totally sufficient here. Just make sure that it has at least 16 characters.

"AppSettings": {
  "Token": "my top secret key"
},

After that, we have to add some package reference to our application.

In Visual Studio Code you can do that by pressing Ctrl + Shift + P, enter Add Package to get the entry NuGet Package Manager: Add Package and then you can enter the desired package.

We need a total of three package references.

The first one is Microsoft.IdentityModel.Tokens. This package includes types that provide support for security tokens and cryptographic operations like signing and verifying signatures. You can always choose the latest version.

After adding the package reference, Visual Studio Code wants to execute the restore command to resolve the new dependencies. Of course, we can do that.

By the way, instead of using the NuGet Package Manager, you could have entered dotnet add package Microsoft.IdentityModel.Tokens into the terminal to add the latest version. Both ways work. It’s up to you what you prefer.

The second package is System.IdentityModel.Tokens.Jwt. This one provides support for creating, serializing and validating JSON web tokens. Exactly what we need.

And the last one is Microsoft.AspNetCore.Authentication.JwtBearer. This is a .NET Core middleware that enables our application to receive bearer tokens.

A bearer token is just a general name for the token we have already discussed. Some servers use short strings as tokens, we will utilize structured JSON web tokens. Both can be called bearer tokens.

Alright. After adding these packages, your .csproj file should be a bit bigger now and include these new references.

<PackageReference Include="Microsoft.IdentityModel.Tokens" Version="5.6.0"/>
<PackageReference Include="System.IdentityModel.Tokens.Jwt" Version="5.6.0"/>
<PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="3.1.2"/>

Now we’re ready to write some code.

JSON Web Tokens (JWT) implementations

In the AuthRepository we start by adding a new private method called CreateToken() that returns a string and takes a User object as an argument.

private string CreateToken(User user)
{
    return string.Empty; //token;
}

Let’s return an empty string for now, so that we can already call this method in the Login() method and set the response.Data accordingly if the user has entered the correct password.

public async Task<ServiceResponse<string>> Login(string username, string password)
{
    ServiceResponse<string> response = new ServiceResponse<string>();
    User user = await _context.Users.FirstOrDefaultAsync(x => x.Username.ToLower().Equals(username.ToLower()));
    if (user == null)
    {
        response.Success = false;
        response.Message = "User not found.";
    }
    else if (!VerifyPasswordHash(password, user.PasswordHash, user.PasswordSalt))
    {
        response.Success = false;
        response.Message = "Wrong password.";
    }
    else
    {
        response.Data = CreateToken(user);
    }
    return response;
}

Back to the CreateToken() method, we declare a List of Claims.

We will have to add some using directives while implementing this method.

The first claim type we add is the ClaimTypes.NameIdentifier. This will be the Id of the given user. The second one is ClaimTypes.Name, which will simply be the Username.

List<Claim> claims = new List<Claim>
{
    new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
    new Claim(ClaimTypes.Name, user.Username)
};

Next, we need a SymmetricSecurityKey. This is the secret key from our appsettings.json file. We need to be able to access the file, so we jump to the constructor of the AuthRepository and inject the IConfiguration. Make sure to add the Microsoft.Extensions.Configuration using directive.

private readonly IConfiguration _configuration;
public AuthRepository(DataContext context, IConfiguration configuration)
{
    _configuration = configuration;
    _context = context;
}

Back to the CreateToken() method, we create an instance of the SymmetricSecurityKey class and give it a byte array. We do that with Encoding.UTF8.GetBytes() and then access the _configuration to get the proper section with our secret key as value.

SymmetricSecurityKey key = new SymmetricSecurityKey(Encoding.UTF8
    .GetBytes(_configuration.GetSection("AppSettings:Token").Value));

With that key, we create new SigningCredentials and use the HmacSha512Signature algorithm for that.

SigningCredentials creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha512Signature);

Next is the SecurityTokenDescriptor. This object gets the information used to create the final token. We’ll give it the claims and an expiration date, for instance.

To set the claims, we set the Subject with a new ClaimsIdentity and give it the claims we created before.

Expires can be set to any date. How about the next day? So DateTime.Now.AddDays(1).

And finally, the SigningCredentials, which is our creds object.

SecurityTokenDescriptor tokenDescriptor = new SecurityTokenDescriptor
{
    Subject = new ClaimsIdentity(claims),
    Expires = DateTime.Now.AddDays(1),
    SigningCredentials = creds
};

We are almost done.

Now we need a new JwtSecurityTokenHandler and use this tokenHandler and the tokenDescriptor to create the SecurityToken.

JwtSecurityTokenHandler tokenHandler = new JwtSecurityTokenHandler();
SecurityToken token = tokenHandler.CreateToken(tokenDescriptor);

And finally, with tokenHandler.WriteToken(token); we return the JSON web token as a string.

private string CreateToken(User user)
{
    List<Claim> claims = new List<Claim>
    {
        new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
        new Claim(ClaimTypes.Name, user.Username)
    };

    SymmetricSecurityKey key = new SymmetricSecurityKey(Encoding.UTF8
        .GetBytes(_configuration.GetSection("AppSettings:Token").Value));

    SigningCredentials creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha512Signature);

    SecurityTokenDescriptor tokenDescriptor = new SecurityTokenDescriptor
    {
        Subject = new ClaimsIdentity(claims),
        Expires = DateTime.Now.AddDays(1),
        SigningCredentials = creds
    };

    JwtSecurityTokenHandler tokenHandler = new JwtSecurityTokenHandler();
    SecurityToken token = tokenHandler.CreateToken(tokenDescriptor);

    return tokenHandler.WriteToken(token);
}

Alright, take a deep breath and let’s test this in Postman. HTTP Method is POST, we use the login URL, the correct credentials and hit ‘Send’.

{
    "data": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJuYW1laWQiOiIxIiwidW5pcXVlX25hbWUiOiJwYXRyaWNrIiwibmJmIjoxNTgyMTA1MDEyLCJleHAiOjE1ODIxOTE0MTIsImlhdCI6MTU4MjEwNTAxMn0.FaxvO8pqLLkBjplEW815-DzekgBwW94gBx--_3n4X5UAs6kRuM2zflpwQ0H2PnCgIuupJKq7EED5c_mC_DI8FQ",
    "success": true,
    "message": null
}

There is our token!

We can grab this token now and have a deeper look at the JWT debugger on jwt.io.

When you paste the token, you’re able to see the claims we have entered in the code.

And if you enter the correct key, the signature can be verified.

Great! So that’s how we get our JSON Web Token.

Authorize Attribute

To secure web service calls or even a complete controller, we can use the [Authorize] attribute on top of the controller class or on top of any method you want to secure. But before we can use this attribute, we have to add an authentication scheme to the web service. We do that in the Startup class.

In the ConfigureServices() method, we use AddAuthentication() with the JwtBearerDefaults.AuthenticationScheme and add some configuration options with AddJwtBearer().

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
});

Regarding the options we initialize a new instance of TokenValidationParameters and set these parameters.

We want to validate the signing key, so we set ValidateIssuerSigningKey to true.

The IssuerSigningKey is again the one from our appsettings.json file. So a new SymmetricSecurityKey that gets the encoded AppSettings:Token value.

We don’t need to validate the issuer or the audience, hence we set ValidateIssuer and ValidateAudience to false.

So far the authentication scheme.

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.ASCII
            .GetBytes(Configuration.GetSection("AppSettings:Token").Value)),
        ValidateIssuer = false,
        ValidateAudience = false
    };
});

Additionally, we have to add the .NET Core AuthenticationMiddleware to the IApplicationBuilder to enable authentication capabilities.

To do that, we add the line app.UseAuthentication(); above app.UseAuthorization();. It’s important to add the line there.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    //app.UseHttpsRedirection();
    app.UseRouting();
    app.UseAuthentication();
    app.UseAuthorization();
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

Alright. With that in place, we can make use of the authentication. To do that we add the [Authorize] attribute on top of the CharacterController class.

[Authorize]
[ApiController]
[Route("[controller]")]
public class CharacterController : ControllerBase

If we now want to get all RPG characters with Postman using GET as HTTP method and the URL http://localhost:5000/character/getall, we get a 401 Unauthorized back.

That’s exactly what we want! So now we have to add a token to the header of our request. Let’s login first to get the JSON web token.

Just copy the token and then go back to the GetAll call.

Here we have to add a header. We add the key Authorization and add the token as value. The token itself is not enough. We have to add the term Bearer with a space in front of the token.

Now we’re finally able to get all RPG characters again.

There’s one little thing I’d like to add here.

To call any method of the CharacterController, we have to be authenticated. But we can make exceptions to the rule. For instance, if we add the attribute [AllowAnonymous] on top of the GetAll() method, we can call this method again without being authenticated.

[AllowAnonymous]
[HttpGet("GetAll")]
public async Task<IActionResult> Get()

In Postman you can see that we can remove the Authorization key in the header and still get the RPG characters from the database.

Let’s remove the attribute again, because we only want authenticated users to get characters.

Actually, we want users to get their created characters. At the moment they can see all RPG characters.

So we have to make use of the relation between users and characters and we also have to get the claims from the authenticated user.

Read Claims & Get the User’s RPG Characters

One of the beauties of the ControllerBase class is that it provides a User object of type ClaimsPrincipal.

// Summary:
//     Gets the System.Security.Claims.ClaimsPrincipal for user associated with the
//     executing action.
public ClaimsPrincipal User { get; }

This User object provides all the claims we added to the JSON web token.

Let’s get the NameIdentifier which was the Id of our authenticated user from the database.

In the Get() method of the CharacterController we define a new int variable.

With User.Claims we access the claims and then we iterate through them or find the one we want with FirstOrDefault() followed by a lambda expression where the Type of the claim equals ClaimTypes.NameIdentifier.

From that result, we grab the Value and parse it to an int.

int id = int.Parse(User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.NameIdentifier).Value);

Now we have to pass this id to the CharacterService. So we make a little change to the GetAllCharacters() method and add the id as an argument in the corresponding interface as well as the service and maybe call this argument userId to avoid any confusion.

Task<ServiceResponse<List<GetCharacterDto>>> GetAllCharacters(int userId);

Then we can call the method with the proper userId we got from the claims and make a slight modification to the service method.

public async Task<IActionResult> Get()
{
    int userId = int.Parse(User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.NameIdentifier).Value);
    return Ok(await _characterService.GetAllCharacters(userId));
}

The only thing we have to change in the GetAllCharacters() method is how we access the Characters from the _context. Instead of returning all of the RPG characters, we make use of the Where() function and only return the characters that are related to the given user with the help of the userId.

List<Character> dbCharacters = await _context.Characters.Where(c => c.User.Id == userId).ToListAsync();

Thanks to Entity Framework we can access the related User object and its Id and actually get the RPG characters that have the proper UserId set in the database table.

When we test that with Postman, we get no characters back. That’s absolutely correct because we haven’t set any relations, yet.

But we can fix that real quick.

In the Characters table, we simply set the UserId of Frodo to 1. Run the test again, and now we’re getting Frodo! Setting the UserId for Sam as well, we’re getting both our heroes back.

Great! This works. Of course, we want to add the relations with our code and not manually in the database every single time. Before we do that, let’s sum up what you have learned in this section.

Summary

Congratulations! You successfully implemented JSON Web Token Authentication in your Web API.

We started by creating the User model and adding this new User as a relation to our RPG characters. This is a one-to-many relation, which means that one user can have several characters.

Then we were already diving into the theory of authentication. You learned how authentication works in general with password hash values and password salts and why you should use hashed values and salts. It’s all about security.

We built the user registration and the user login and used a specific cryptography algorithm to hash and verify the entered passwords.

After that, we covered token authentication with JSON web tokens.

You now know what a bearer token is, what you find in that token - like the used algorithm and the payload - and how you can add any claims you want to add to that token.

So you learned how you can create a JSON web token and how to secure your Web API with the [Authorize] attribute. While doing that, you also learned how to read the claims from the JSON web token and use them to return the correct data to the user.

Great! Now it’s time to add some more relations to our application. What about some skills to use during fights, for instance? And, of course, let’s add the correct relation between users and characters as soon as a character has been generated.

We do all that in the next section.

That's it for the 8th part of this tutorial series. I hope it was useful for you. To get notified for the next part, simply follow me here on dev.to or subscribe to my newsletter. You'll be the first to know.

See you next time!

Take care.

Next up: Advanced Relationships with Entity Framework Core

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.

Basic Authentication with a .NET Core Web API

Patrick God — Fri, 06 Mar 2020 16:03:01 +0000

Authentication

Introduction

Welcome to the authentication section.

In this section, we will add users to our role-playing game. Users will be able to create an account and add RPG characters to that account.

So, with that, we will also introduce JSON Web Tokens. These tokens will be used to authenticate the user, meaning we’re making sure that this particular user is allowed to select certain characters, update them, and so on.

Additionally, with users and their characters, we already introduce the first relation in our database. One user can have several RPG characters.

But before we get to the details, let’s start with the new user model

The User Model

To add the user model, we create a new C# class in the Models folder and call this class User.

Let’s keep this User model simple. We give the user an Id of type int, a Username of type string, and we need a password, of course. But this won’t just be a password string. We actually want to save a hash value of the password and we also need a salt to create a unique password hash. And these two properties will be byte arrays.

So, let’s add two byte arrays, the PasswordHash and the PasswordSalt.

public class User
{
    public int Id { get; set; }
    public string Username { get; set; }
    public byte[] PasswordHash { get; set; }
    public byte[] PasswordSalt { get; set; }
}

That’s it for now. Let’s run another migration to see the new User model in the database.

Remember, we have to add another DbSet<> so that Entity Framework knows what tables to create.

We add the new DbSet<User> in the DataContext class.

public DbSet<User> Users { get; set; }

Again, we simply pluralize the type User to get a suitable table name.

Now we can run the migration. First, in the terminal, we enter dotnet ef migrations add User to add the User to the migration.

In the file explorer, we find our new migration. When we have a look at the migration file, we see the Up() and Down() methods again. Similar to the migration of the RPG character, a corresponding database table will be created with all its fields and the Id as the primary key.

Let’s add this table with dotnet ef database update.

After the successful update, we can see the Users table in our database

But what about a relation? Users should be able to have several RPG characters.

Let’s add that relation now.

First Relation

There are three types of relations in a relational database, one-to-one, one-to-many and many-to-many.

What does that mean?

A one-to-one relation is pretty simple. In our example, this would mean that a user would only have one RPG character. And this RPG character only has this one particular user. These two entities are linked and when you know the user, you can also identify the character and vice versa. The user cannot have another character. The same states for the character.

A one-to-many relationship is what we want to implement. A user can have several RPG characters. But the characters are only linked to that single user. One user, many characters.

If the same characters would be linked to different users, we would have a many-to-many relationship. In essence, this would mean that RPG characters are shared amongst several users. This could be an interesting concept, but we’ll stick to the one-to-many relationship.

More suitable for a many-to-many relationship would be a relation between characters and skills. For instance, several magicians could have several skills like throwing fireballs or summoning creatures. We’ll do something like that later.

To realize the one-to-many relationship between users and characters, we add properties to our models.

First, the User gets a List<> of RPG characters.

public List<Character> Characters { get; set; }

Actually, that’s already sufficient. That way we’re able to select all characters of a particular user.

But what about the other way around? We have an RPG character and want to select the corresponding user? To be able to do that, we add a User property to the Character model, as well.

public User User { get; set; }

Now we’ve got our relationship. Let’s add a migration again with dotnet ef migrations add UserCharacterRelation.

The Up() method is different now. It adds a new column UserId to the Characters table and also defines an index and a foreign key to the column Id of the Users table. That’s how the relationship is defined in the database.

protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.AddColumn<int>(
        name: "UserId",
        table: "Characters",
        nullable: true);
    migrationBuilder.CreateIndex(
        name: "IX_Characters_UserId",
        table: "Characters",
        column: "UserId");
    migrationBuilder.AddForeignKey(
        name: "FK_Characters_Users_UserId",
        table: "Characters",
        column: "UserId",
        principalTable: "Users",
        principalColumn: "Id",
        onDelete: ReferentialAction.Restrict);
}

It’s interesting to mention, that onDelete is set to ReferentialAction.Restrict. This means that you can’t delete a user if he or she still has a character. Another option would be Cascade. In that case, all characters of the user will be deleted, if the user would be deleted.

The Down() method looks pretty straight forward. It would just revert the actions of the Up() method, meaning removing the foreign key, the index, and the new column.

Let’s update the database now with dotnet ef database update.

You see, our Characters now have a UserId and we’re able to create some relations.

But before we let users create any RPG characters, let’s implement the authentication first.

Authentication Theory

So, how would the authentication work in general?

You have already seen that we want to store the password of the user as a hashed value. The other option would be to store the password in plain text and when the user is trying to log in, we just compare the entered value with the stored value. But that's absolutely not recommended. Even big websites get hacked, database leaks happen, it's just not secure at all. And you would see all the passwords of your users. I guess they wouldn't like that at all.

That's why we're using a hash value. But even hashing a password is not enough.

To hash a password we're using a particular cryptography algorithm like HMACSHA512, for instance. That algorithm is always the same, hence the hash of a certain password is also always the same.

So, you would see if users use the same passwords and, much worse, there are tools that can revert these algorithms and so receive the plain password in seconds via brute force.

And that's why we're also using a password salt. A salt can be a random sequence of letters and numbers that is used together with the actual password.

The algorithm gets the password and a salt as input so that it produces different hash values even with the same password.

To be able to get the correct result, we store the password salt in the database.

How does this look in the end?

When the user registers with a password, we grab this password, generate a random salt, throw both into the algorithm and get a beautiful final hash value.

When the user wants to log in with that password, we actually do the same, except grabbing the stored salt from the database. The resulting hash value will be compared to the stored hash value and if both values are the same, the user is successfully authenticated.

So far the theory. Let's build that now.

Authentication Repository

For the implementation of the authentication, we're using the repository pattern. You already know it a bit from our DataContext and we’re actually using this pattern already with our CharacterService. Since we’re using this again now, I think it’s time to explain that a bit.

The documentation from Microsoft describes repositories pretty well.

Well, this is very technical, so let’s break this down a little.

Thanks to Entity Framework, we don’t have to write the SQL statements ourselves and we don’t have to worry about setting up the database connection every time we want to access the entities of the database.

We just use Entity Framework to do all this with the help of the DbContext. So, we inject the DataContext into a C# class and we’re already able to access the database. If anything changes in the database or we want to use another database, we still use the DataContext to run all operations. We don’t have to change our code!

And that’s already the repository pattern in essence. We already do the same with the CharacterService. This service or repository enables our CharacterController to access all RPG character operations by injecting the ICharacterService interface. Any other controller could do the same. And if the code in the CharacterService methods changes, we don’t have to touch the controllers, because they just access the methods via the injected class.

We register the repository as a service in the Startup class in the ConfigureServices() method. Here we’re telling our application which implementation should be used if a service wants to inject a certain interface.

This means, we could create a CharacterService2, change the single line in the Startup class and everything works just fine with the new implementation.

That’s the magic of dependency injection and the repository pattern.

Enough with the theory.

Let’s create an interface and a C# class for authentication.

In the Data folder we create the interface IAuthRepository and also the class AuthRepository which implements the interface, of course.

public class AuthRepository : IAuthRepository
{

}

The interface gets three methods. The first is Register() with a User and a string as parameter and returning an int - the Id of the user, second method is Login() with two string parameters and returning a token as string, and the last method is UserExists() with the username as string to check if the user already exists. Notice that the last method does not return a ServiceResponse. This would be a bit over the top.

public interface IAuthRepository
{
    Task<ServiceResponse<int>> Register(User user, string password);
    Task<ServiceResponse<string>> Login(string username, string password);
    Task<bool> UserExists(string username);
}

Alright, let’s implement the methods by using the quick fix menu and then let’s start with the user registration.

User Registration

Registering a new user is nothing else than creating a new user in the database.

That’s not the whole magic, of course, but let’s start with this idea. To access the database, we need the DataContext again. So we add the constructor for the AuthRepository and inject the DataContext.

private readonly DataContext _context;

public AuthRepository(DataContext context)
{
    _context = context;
}

Next, in the Register() method, we could simply access the _context, add this new user, save all changes, create the ServiceResponse and send the new Id of the user back, because adding the new user generates a new id.

public async Task<ServiceResponse<int>> Register(User user, string password)
{
    await _context.Users.AddAsync(user);
    await _context.SaveChangesAsync();
    ServiceResponse<int> response = new ServiceResponse<int>();
    response.Data = user.Id;
    return response;
}

Do you see the problem with this? What's up with the password?

If we would just use the given password string like that, it would be stored in plain text in the database. Not good.

So, let’s write a method to hash the password.

At the bottom, we create a private method CreatePasswordHash with the parameter password and also two out parameters passwordHash and passwordSalt. These last two will be stored in the database.

Now it’s getting interesting. We’re using the HMACSHA512 cryptography algorithm to generate a key and create the password hash. It can be found in the System.Security.Cryptography namespace.

Creating an instance of this class already generates a key that can be used as password salt. So, our passwordSalt is the hmac.Key.

After that, we use the class to generate a hash with the method ComputeHash() which takes the given password as bytes.

private void CreatePasswordHash(string password, out byte[] passwordHash, out byte[] passwordSalt)
{
    using (var hmac = new System.Security.Cryptography.HMACSHA512())
    {
        passwordSalt = hmac.Key;
        passwordHash = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(password));
    }
}

That’s it. With the help of the out keywords we don’t need to return anything, the hash and salt are already available in the Register() method. So, let’s use this new method now.

At the top of the Register() method, we call CreatePasswordHash() with the given password and the new byte[] variables passwordHash and passwordSalt.

Then we set the hash and salt of the user object.

public async Task<ServiceResponse<int>> Register(User user, string password)
{
    CreatePasswordHash(password, out byte[] passwordHash, out byte[] passwordSalt);

    user.PasswordHash = passwordHash;
    user.PasswordSalt = passwordSalt;

    await _context.Users.AddAsync(user);
    await _context.SaveChangesAsync();

    ServiceResponse<int> response = new ServiceResponse<int>();
    response.Data = user.Id;
    return response;
}

We’re almost done. Remember, we have to check if the user already exists. That’s what we do next.

“User already exists.”

The implementation is pretty straight forward.

We add the async keyword to the method and then start with an if statement where we access the _context and check if a user with the same username already exists by calling the method AnyAsync() followed by a lambda expression. We need the Microsoft.EntityFrameworkCore using directive for that. We also turn the usernames to lowercase.

If the user already exists, we return true, in the other case, we return false. Simple as that.

public async Task<bool> UserExists(string username)
{
    if (await _context.Users.AnyAsync(x => x.Username.ToLower() == username.ToLower()))
    {
        return true;
    }
    return false;
}

You see, using a ServiceResponse in this method would be a bit over the top. We could even use a private method in this case. But maybe we need the method in a controller someday, so it doesn’t hurt to make this method publicly available.

Going back to the Register() method, we move the declaration of the resulting ServiceResponse to the top.

After that, we call our UserExists() method, and if the user does exist, we return the response with Success = false and a Message like User already exists..

public async Task<ServiceResponse<int>> Register(User user, string password)
{
    ServiceResponse<int> response = new ServiceResponse<int>();
    if (await UserExists(user.Username))
    {
        response.Success = false;
        response.Message = "User already exists.";
        return response;
    }
    CreatePasswordHash(password, out byte[] passwordHash, out byte[] passwordSalt);
    user.PasswordHash = passwordHash;
    user.PasswordSalt = passwordSalt;
    await _context.Users.AddAsync(user);
    await _context.SaveChangesAsync();
    response.Data = user.Id;
    return response;
}

So far, so good. To test this, we need a controller now. Let’s do that next.

Authentication Controller

We add a new C# class AuthController in the Controllers folder, derive from ControllerBase, add the usual attributes and the Microsoft.AspNetCore.Mvc using directive.

[ApiController]
[Route("[controller]")]
public class AuthController : ControllerBase
{

}

From here we create a constructor and inject the IAuthRepository. We add dotnet_rpg.Data to our class and initialize the field authRepo from the parameter. If you want, you can also change the name and add an underscore.

private readonly IAuthRepository _authRepo;
public AuthController(IAuthRepository authRepository)
{
    _authRepo = authRepository;
}

Now, we add the Register() method. Starting with the signature of the method, we have to add the System.Threading.Tasks namespace and then we already see that we need a new DTO for the request. We could send the username and the password via the URL, but this is not recommended. It’s better to hide this information in the body.

So, let’s add a UserRegisterDto real quick. We create a folder User and then add a new C# class with two properties, the Username and the Password, both as string.

public class UserRegisterDto
{
    public string Username { get; set; }
    public string Password { get; set; }
}

Now we can use this DTO as a request object in the Register() method.

public async Task<IActionResult> Register(UserRegisterDto request)
{

}

We declare a ServiceResponse and call the Register() method of the _authRepo. The idea behind the User parameter is, that we could add more information to the user upon registration, like an email address, birthdate, favorite color and so on. That’s why we use that object. Again, that’s totally up to you and you could rewrite the necessary methods to just send a username and a password without any additional information.

After the registration call, we check if the Success member of the response is false. If so, we return a BadRequest(), otherwise we return 200 OK.

One last thing is missing. We add the attribute [HttpPost] with the route ”Register” on top of the method.

[HttpPost(“Register”)]
public async Task<IActionResult> Register(UserRegisterDto request)
{
    ServiceResponse<int> response = await _authRepo.Register(
        new User { Username = request.Username }, request.Password);
    if(!response.Success) {
        return BadRequest(response);
    }
    return Ok(response);
}

Finally, we have to register the AuthRepository in our Startup class. Similar to the CharacterService we can do that with AddScoped() and then the interface and the implementation class of the AuthRepository.

services.AddScoped<IAuthRepository, AuthRepository>();

Alright, start the Web API with dotnet watch run if it isn’t running and then let’s test the registration with Postman.

The HTTP method is POST, the URL is http://localhost:5000/auth/register and then we have to add a JSON body with a username and a password.

{
    "username":"patrick",
    "password": "123456"
}

The result is the usual ServiceResponse with the Id of the created User in the data field.

{
    "data": 1,
    "success": true,
    "message": null
}

We can also find the new user in the database.

Here we can also see that the id of the new user is 1 and that the password hash and the salt are binary data.

If we try to register with the exact same name again, we get the expected failing result back.

{
    "data": 0,
    "success": false,
    "message": "User already exists."
}

Any kind of front end could read that now and display the message to the user.

Great! So, the account registration works. Let’s build the login next.

User Login

Before we use any kind of token authentication, we will first implement the basic login and return the Id of the user as ServiceResponse.Data. Later, we will find the token here.

First, we need a method to verify the given password. Let’s call it VerifyPasswordHash() and return a boolean value to tell if the password is correct or not. The parameters are the password the user has entered, and the passwordHash as well as the passwordSalt of the user from the database.

With this information, we create a new instance of the HMACSHA512 class with the passwordSalt as key data. With that instance and the entered password we compute a new hash value.

This computedHash value will then be compared with the passwordHash from the database byte by byte. We use a simple for loop for that.

If the current byte value of the computedHash does not equal the passwordHash value with the same index, we know that the password is wrong. Otherwise, if the for loop went through with no unequal value, everything is fine and the user has been authenticated successfully.

private bool VerifyPasswordHash(string password, byte[] passwordHash, byte[] passwordSalt)
{
    using (var hmac = new System.Security.Cryptography.HMACSHA512(passwordSalt))
    {
        var computedHash = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(password));
        for (int i = 0; i < computedHash.Length; i++)
        {
            if (computedHash[i] != passwordHash[i])
            {
                return false;
            }
        }
        return true;
    }
}

Now we can build the login method and use the VerifyPasswordHash() method there.

First we add the async keyword and initialize a new ServiceResponse.

Then we have to find the requested user first. As usual, we do that by accessing the _context and try to find the user with the given username.

If no user has been found, we send a failing ServiceResponse back and maybe a message as well.

Regarding the message, always take into account that you already reveal useful information to a potential attacker if you tell specifically that the user has not been found or that the password has been wrong. In these cases, an attacker would know that a particular user exists (it’s more critical with email addresses) and he or she could try to find the correct password with a brute force attack.

Anyways, since our application is just an example, let’s go with “User not found”. That way it’s easier for us to see if our web service works as expected.

Alright, we got the username covered, now we check if the password is correct. We finally call the VerifyPasswordHash() method with the entered password, and the PasswordHash and the PasswordSalt of the user from the database.

If the password is wrong, we send a failing ServiceResponse back again.

Finally, if the password is correct, we send the Id of the user back. As already mentioned, later we’ll send the token back here.

public async Task<ServiceResponse<string>> Login(string username, string password)
{
    ServiceResponse<string> response = new ServiceResponse<string>();
    User user = await _context.Users.FirstOrDefaultAsync(x => x.Username.ToLower().Equals(username.ToLower()));
    if (user == null)
    {
        response.Success = false;
        response.Message = "User not found.";
    }
    else if (!VerifyPasswordHash(password, user.PasswordHash, user.PasswordSalt))
    {
        response.Success = false;
        response.Message = "Wrong password.";
    }
    else
    {
        response.Data = user.Id.ToString();
    }

    return response;
}

Now we have to call this Login() method with the help of the AuthController.

But first, we create a new UserLoginDto with two properties, the Username and the Password. I know, it’s exactly the same as the UserRegisterDto. But again, maybe you want to add more information to the registration later, so if you split the DTOs now, you don’t have to do it later.

Back to the AuthController we add the Login() method. We can actually copy the Register() method and just make some small changes.

We change the route, the method name and the parameter type first.

The ServiceResponse type is now a string, we call the Login() method of the _authRepo and give that method the request.Username and the request.Password.

[HttpPost("Login")]
public async Task<IActionResult> Login(UserLoginDto request)
{
    ServiceResponse<string> response = await _authRepo.Login(
        request.Username, request.Password);
    if(!response.Success) {
        return BadRequest(response);
    }
    return Ok(response);
}

That’s it already. Let’s test that now in Postman. We should still have the user available from the registration. So we can use the same JSON body, the HTTP method is still POST, but the route is now login.

Great. We get the correct id back.

What happens if the username is wrong?

{
    "data": null,
    "success": false,
    "message": "User not found."
}

The user has not been found. What about a wrong password?

{
    "data": null,
    "success": false,
    "message": "Wrong password."
}

We get the information that the password is indeed wrong.

Perfect.

It’s time to move on with token authentication.

That's it for the 7th part of this tutorial series. I hope it was useful for you. To get notified for the next part, simply follow me here on dev.to or subscribe to my newsletter. You'll be the first to know.

See you next time!

Take care.

Next up: Authentication with JSON Web Tokens in .NET Core

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.

All CRUD Operations with Entity Framework Core (GET, POST, PUT & DELETE)

Patrick God — Mon, 02 Mar 2020 16:30:35 +0000

Entity Framework Core (continued)

GET Implementations

The very first thing we have to do to be able to access our RPG characters is to get access to the DataContext. We make use of dependency injection for that and add the context to the constructor of our CharacterService. Again, we can initialize this field from the parameter and change the name a little bit.



private readonly DataContext _context;
public CharacterService(IMapper mapper, DataContext context)
{
    _context = context;
    _mapper = mapper;
}

With that, the _context is available everywhere in our CharacterService.

In the GetAllCharacters() method we add a new line to get the characters from the database.



List<Character> dbCharacters = await _context.Characters.ToListAsync();

Then, instead of selecting the static characters list, we use our new dbCharacters.



public async Task<ServiceResponse<List<GetCharacterDto>>> GetAllCharacters()
{
    ServiceResponse<List<GetCharacterDto>> serviceResponse = new ServiceResponse<List<GetCharacterDto>>();
    List<Character> dbCharacters = await _context.Characters.ToListAsync();
    serviceResponse.Data = dbCharacters.Select(c => _mapper.Map<GetCharacterDto>(c)).ToList();
    return serviceResponse;
}

These are all the necessary changes. When we test that in Postman - URL is http://localhost:5000/Character/GetAll - we get no characters back, of course, because we haven’t added any characters in the database yet. So let’s add one in the SQL Server Management Studio.

We don’t have to enter an Id, just the name, hitpoints, and so on, and confirm the new entry with enter.

Let’s run another test and there is our Frodo.



{
    "data": [
        {
            "id": 1,
            "name": "Frodo",
            "hitPoints": 100,
            "strength": 10,
            "defense": 10,
            "intelligence": 10,
            "class": 1
        }
    ],
    "success": true,
    "message": null
}

Receiving a single RPG character is quite similar.

Let’s get the database character first. We do that with Character dbCharacter = await _context.Characters.FirstOrDefaultAsync(c => c.Id == id);.

Then we simply map that dbCharacter.



public async Task<ServiceResponse<GetCharacterDto>> GetCharacterById(int id)
{
    ServiceResponse<GetCharacterDto> serviceResponse = new ServiceResponse<GetCharacterDto>();
    Character dbCharacter = await _context.Characters.FirstOrDefaultAsync(c => c.Id == id);
    serviceResponse.Data = _mapper.Map<GetCharacterDto>(dbCharacter);
    return serviceResponse;
}

By the way, you see that the yellow lines have disappeared because we’re finally using asynchronous methods. That’s cool, isn’t it?

Anyways, to test the new GetCharacterById() method, let’s add a second character to the database manually.

I’d like to call this guy Sam again.

Again, entering an Id is not necessary, SQL Server is doing this for us.

Alright. Back to Postman with the URL http://localhost:5000/Character/2 and we’re getting Sam back.



{
    "data": {
        "id": 2,
        "name": "Sam",
        "hitPoints": 100,
        "strength": 10,
        "defense": 10,
        "intelligence": 10,
        "class": 1
    },
    "success": true,
    "message": null
}

Let’s get all RPG characters again.



{
    "data": [
        {
            "id": 1,
            "name": "Frodo",
            "hitPoints": 100,
            "strength": 10,
            "defense": 10,
            "intelligence": 10,
            "class": 1
        },
        {
            "id": 2,
            "name": "Sam",
            "hitPoints": 100,
            "strength": 10,
            "defense": 10,
            "intelligence": 10,
            "class": 1
        }
    ],
    "success": true,
    "message": null
}

There are our mighty knights.

POST Implementations

When we want to add an RPG character to the database, the first thing that stands out is that we don’t need to increase the Id manually. SQL Server will do this for us.

Apart from that, we won’t add the character to the static characters list anymore.

Instead, we use the AddAsync() method to add the RPG character to the database.



await _context.Characters.AddAsync(character);

The next step is very important.

Since we made a change to the database, we have to save these changes explicitly. We do that with await _context.SaveChangesAsync().

Last but not least, we return all RPG characters from the database.



public async Task<ServiceResponse<List<GetCharacterDto>>> AddCharacter(AddCharacterDto newCharacter)
{
    ServiceResponse<List<GetCharacterDto>> serviceResponse = new ServiceResponse<List<GetCharacterDto>>();
    Character character = _mapper.Map<Character>(newCharacter);

    await _context.Characters.AddAsync(character);
    await _context.SaveChangesAsync();
    serviceResponse.Data = (_context.Characters.Select(c => _mapper.Map<GetCharacterDto>(c))).ToList();
    return serviceResponse;
}

That’s it!

Let’s test that in Postman. The URL is http://localhost:5000/Character/, the HTTP method is POST, and we send a JSON in the body with just the name, hitpoints and another class for starters.



{
    "name" : "Percival",
    "hitpoints" : 200,
    "class": 2
}

Again, we don’t have to send an Id and we don’t have to set it manually in the service. When we run this, we get all RPG characters back, and we can see the new entry in the database.

PUT Implementations

To update an RPG character, we first have to find a particular character in the database.

Instead of searching for the character with the given Id in the static characters list, we access the characters of the data context and search the RPG characters asynchronously.



Character character = await _context.Characters.FirstOrDefaultAsync(c => c.Id == updatedCharacter.Id);

Overriding the properties stays the same.

But after that, we have to access the data context again and call the Update() method on that particular character.

Since we made a change to the character table, we have to save these changes again with await _context.SaveChangesAsync();.



_context.Characters.Update(character);
await _context.SaveChangesAsync();

That’s it already!

Receiving the particular RPG character from the database, change the values, update the character in the database and save the changes again.

Again, it’s time to test that in Postman.

Let's receive a single character first. With the help of the result, we already have the proper JSON object to use for the update call. Let’s get Frodo with Id 1, for instance.



{
    "id": 1,
    "name": "Frodo",
    "hitPoints": 100,
    "strength": 10,
    "defense": 10,
    "intelligence": 10,
    "class": 1
}

Now, we can update Frodo’s properties with the URL http://localhost:5000/Character/, the HTTP method PUT and this JSON object here.



{
    "id": 1,
    "name": "Frodo",
    "hitPoints": 200,
    "strength": 20,
    "defense": 10,
    "intelligence": 10,
    "class": 2
}

You can change anything you want except the Id, of course, because that’s how we find the correct RPG character.

When we run this call, we get the correct result and we can also see the changes in the SQL Server Management Studio.

Remember, all properties of the characters will be changed in our update method. So make sure to get the correct values of the character first or implement methods to update single properties. Otherwise, you would overwrite the properties of a character with default values.

Just keep that in mind.

DELETE Implementations

Alright, only deleting a character is left and then you know how to implement all the CRUD operations with Entity Framework Core.

First, let’s remove the static characters list because we won’t need it anymore.

Of course, this results in some errors in our DeleteCharacter() method, because this is the only method left using the characters list.

But don’t worry, we’ll fix that right now. Maybe you already know how to fix this.

In essence, we have to replace the old characters list with _context.Characters.



Character character = _context.Characters.First(c => c.Id == id);
_context.Characters.Remove(character);

serviceResponse.Data = (_context.Characters.Select(c => _mapper.Map<GetCharacterDto>(c))).ToList();

After that, we call the asynchronous FirstAsync() method instead of First(). Don’t forget to add the await keyword.



Character character = await _context.Characters.FirstAsync(c => c.Id == id);

Now, only one thing is missing. We have to save the changes to the database. So let’s call await _context.SaveChangesAsync(); and we’re done.



Character character = await _context.Characters.FirstAsync(c => c.Id == id);
_context.Characters.Remove(character);
await _context.SaveChangesAsync();

serviceResponse.Data = (_context.Characters.Select(c => _mapper.Map<GetCharacterDto>(c))).ToList();

To test this in Postman, we can remove the RPG character with Id 3, for instance. The URL is http://localhost:5000/Character/3 and the HTTP method is DELETE. Hit ‘Send’, and the character is gone. You can also see that in the database table, of course.

Summary

Great! You successfully implemented all CRUD operations, meaning create, read, update and delete, with Entity Framework Core.

All your changes are now stored persistently in the database.

You now know what object-relational mapping is, how code-first migration works and how to use it with a SQL Server database. Additionally, you looked at your database with SQL Server Management Studio.

Regarding the code, you learned what the DbContext is and how to provide a connection string to access the database with all its entities.

Alright, it’s time to add the first relation to the RPG characters.

In the next section, we will add users who can own several characters. But before they can do that, they have to register for an account. So, in the next section, we will add a relation and also implement authentication.

That's it for the 6th part of this tutorial series. I hope it was useful for you. To get notified for the next part, simply follow me here on dev.to or subscribe to my newsletter. You'll be the first to know.

See you next time!

Take care.

Next up: Basic Authentication with a .NET Core Web API

Image created by cornecoba on freepik.com.

But wait, there’s more!

Let’s connect on Twitter, YouTube, LinkedIn or here on dev.to.
Get the 5 Software Developer’s Career Hacks for free.
Enjoy more valuable articles for your developer life and career on patrickgod.com.