Introduction to ASP.NET Core part 28: summary

Introduction

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

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

Read more of this post

Introduction to ASP.NET Core part 27: showing the user status and logging out

Introduction

In the previous post we looked at the basics of authorisation and the log in process in .NET Core. The Authorization attribute which can be used for controllers and action methods helps us introduce a basic form of restrictions. The visitor must be logged in in order to reach the restricted sections in the application. The login process is handled by the built-in SignInManager service class. It offers a range of functions related to the user’s state. We also saw the importance of the return URL property which enables us to redirect the user to the page that they wanted to visit before logging in.

In this post we’ll look at how to log out and how to show the user’s status in the top section of each page.

Read more of this post

Introduction to ASP.NET Core part 26: authorisation basics and logging in

Introduction

In the previous post we continued looking into the basics of user management in .NET Core. We first created a separate database for our users and related objects such as claims and tokens. We then went on and created the components necessary for user creation: the view, the account controller and the user registration view model. We used the built-in generic UserManager of T for the database section of user management. The UserManager object provides a wide range of functions to handle users: insert a new user, retrieve a user by ID, confirm an email and much more. Therefore UserManager is an out-of-the-box service class to connect the application user and the database.

In this post we’ll investigate the basics of what to do with our users: authorisation and logging in.

Read more of this post

Introduction to ASP.NET Core part 25: user management cont’d

Introduction

In the previous post we started looking into user management in .NET Core MVC. .NET Core provides a number of built-in objects for this purpose: so far we’ve seen IdentityUser to represent the properties of a typical application user, IdentityRole to represent roles and the generic IdentityDbContext of T class to easily connect the application with an SQL Server based identity provider. The built in objects can be customised by deriving a class from them like we did with our UserManagementDbContext and User classes. We also saw how to install and register the EF based identity provider in Startup.cs via the Configure and ConfigureServices methods. We keep the user management related elements separate from the bookstore domain so that users, claims, roles etc. do not intermingle with our core domain.

Currently our demo application doesn’t do anything with users. Any visitor can do anything on the books related pages. We’ll start building out our application around that in this post.

Read more of this post

Introduction to ASP.NET Core part 24: handling users

Introduction

In the previous post we added the EntityFramework repository elements to our demo project. The book entities are now saved in and extracted from a database. We successfully replaced the in-memory placeholder repository with one backed up by SQL Server. We implemented the EF repository so that it has a separate commit function that needs to be called to persist the changes. The service class calling on the repository has an extra step to make but this way it’s possible to call AddNew several times and then CommitChanges only once. We’ll therefore not send a query to the database after each and every call to AddNew but send a single set of instructions instead.

In this post we’ll start looking into how to handle users in .NET Core MVC. We’ll be using the user management features built into .NET Core and EF Core. User management is most often not part of the core business domain and using the well tested built-in security features can save us a lot of time. That is time that we can spend on the real business domain of the application. In addition they can help us with the login and logout process.

We’ll also try and separate the user related elements from the “real” business entities of our application. That is we’ll put the users in a separate database with its own data context and connection string.

Read more of this post

Introduction to ASP.NET Core part 23: the EntityFramework repository

Introduction

In the previous post we started looking into EntityFramework Core. We saw how to install and wire up EF Core using NuGet and Startup.cs. We also discussed the basics of creating a DB context class with a single DB set of the Book domain. The Update-Database command in the package manager detects our DB context class in the project and creates a data migration file. The console also enabled us to create the database and the Books table table using code-first and EF data migrations with the help of the generated migration class. That’s where we can declare in code what type of objects we want to create in the database: tables, indexes, primary keys etc.

The next step is to actually use this database in our demo book store project. We’ll do that in this post.

Read more of this post

Introduction to ASP.NET Core part 22: wiring up EntityFramework Core

Introduction

In the previous post we looked at a new feature in .NET Core called view components. A view component is sort of a mixture between full-blown controllers and partial views. It has its own controller and view but is supposed to be viewed and invoked within a parent view. A view component controller can have its own dependencies injected into it via its constructor just like in the case of “real” controllers. It is a normal C# class which can have its own functions and input parameters. We can implement either the Invoke or InvokeAsync function to return a view depending on whether we want to execute the view component asynchronously or not. The view returned by a view component controller is a cshtml file which will be rendered within a parent view. Thus a view component offers a lot more flexibility than a partial view when breaking out a smaller part of a view.

In this post we’ll start looking at EntityFramework Core which will provide a data store to our application.

Read more of this post

Introduction to ASP.NET Core part 21: view components

Introduction

In the previous post we looked at partial views. Partial views have been around for a long time in ASP.NET MVC and they work in much the same way in .NET Core MVC. Partial views are a means of factoring out parts of a view into smaller, reusable and more manageable units. Partial views can also have their own dependencies. So they behave just like “full” views but are meant to be rendered within a parent view.

In this post we’ll look at an alternative to partial views called view components. View components are new in this version of MVC.

Read more of this post

Introduction to ASP.NET Core part 20: partial views

Introduction

In the previous post we looked at dependency injection in cshtml views. The @inject directive can be used to inject abstract and concrete types into views. We saw an example of the Layout view using an injected IStringFormatter interface to present some message. This abstraction was wired up in Startup.cs so that it is correctly initialised when injected. Normally though views should not depend on these services. The controller which serves up a view should pass in all the necessary arguments into it so that it can build its HTML content. So it’s a useful enhancement to the framework but use it sparingly otherwise the view will be “too clever” and perform actions it is not supposed to do.

In this post we’ll look briefly at partial views.

Read more of this post

Introduction to ASP.NET Core part 19: dependency injection into views

Introduction

In the previous post we saw some other examples of creating custom views in .NET Core MVC. We first discussed how to set the HTML content before and after some text using the “spandec” custom attribute. It enclosed a piece of text within a span element and added a class attribute to the span element as well. We then saw how easy it was to provide the custom tag with an object from the HTML markup using an attribute. Therefore we’re not confined to supplying primitive types to custom tags as arguments. Lastly we saw how to create a conditional tag helper to filter out specific Book records based on an if-condition.

In this post we’ll briefly look at dependency injection into views.

Read more of this post