How to Install the Django on Ubuntu 22.04 ?

 

This article will provide some of the most important example how to install the django on ubuntu 22.04?. we will help you to give example of ubuntu 20.04 on install the django web framework. you will learn guide to install the django web framework. you can see steps to install the django web framework on ubuntu 22.04.

You can use this post for ubuntu 14.04, ubuntu 16.04, ubuntu 18.4, ubuntu 20.04, ubuntu 21 and ubuntu 22.04 versions.

Use the following steps to install and uninstall django web framework on ubuntu 22.04:

Step 1 – Update System Dependencies

Step 2 – Install Django

Step 3 – Verify Installation

Step 4 – Uninstall Django

Step 1: Update System Dependencies

Run the following command on the command line to update system dependencies:

sudo apt update

Step 2: Install Django

Run the following command to install Django Web Framework:

sudo apt install python3-django -y

Step 3: Verify Installation

Run the following command to test the Django installation:

django-admin --version

Step 4: Uninstall Django

To remove this installed package of Django use the purge command:

sudo apt purge python3-django -y

Angular Lazy Loading

 

Create a New Module

So let’s start with the Angular CLI command for the module creation:

ng g module owner --routing=true --module app.module

This command does several things. It creates a new Owner module, it also creates a routing file for that module, and finally, updates the App module file:

CREATE src/app/owner/owner-routing.module.ts (248 bytes)

CREATE src/app/owner/owner.module.ts (276 bytes)

UPDATE src/app/app.module.ts (989 bytes)

Let’s inspect the owner.module.ts file:

import { NgModule } from '@angular/core';

import { CommonModule } from '@angular/common';

import { OwnerRoutingModule } from './owner-routing.module';

@NgModule({

declarations: [],

imports: [

CommonModule,

OwnerRoutingModule

]

})

export class OwnerModule { }

There are two small differences between this module file and the app module file. The first difference is that in the app module file we have an import statement for the BrowserModule, and in the owner module file, we have an import statement for the CommonModule. That’s because the BrowserModule is only related to the root module in the application.

The second difference is that we don’t have the providers array inside the owner module file. That’s because we should register all the services in the root module. That way components will inject the same instance of the service only once and you can keep the state in your service.

Of course, if we really want to register a service inside any child module, we could just add the providers array. But, by doing so we cannot keep the state inside our service because every time we create a new instance of that component a new instance of a service is created.

Finally, we can see that this module imports the OwnerRoutingModule from a separate file.

Owner Component and Angular Lazy Loading

Let’s start with the creation of the owner component files:

ng g component owner/owner-list --skip-tests

This command is going to create the required folder structure and it is going to import this component inside the owner.module.ts file as well.

What we want now is, when we click on the “Owner-Actions” menu, to show the content from this component’s HTML file. So first, just for the testing purposes, let’s modify the owner.component.html file by adding one paragraph (<p> tag):

<p>This is owner-list component page.</p>

After that, let’s modify the app-routing.module.ts file:

const routes: Routes = [

{ path: 'home', component: HomeComponent },

{ path: 'owner', loadChildren: () => import('./owner/owner.module').then(m => m.OwnerModule) },

{ path: '404', component: NotFoundComponent },

{ path: '', redirectTo: '/home', pathMatch: 'full' },

{ path: '**', redirectTo: '/404', pathMatch: 'full' }

];

With the modified part of the code, we are configuring the app-routing.module to load the owner module whenever someone searches for the http://localhost:4200/owner endpoint. As we can notice, we are using the loadChildren property which means, that the owner module with its components won’t be loaded until we explicitly ask for them. By doing this, we are configuring Angular lazy loading from the owner module content.

Now if we navigate to the Home page, we will get only resources from the root module, not from the owner module. And only by navigating to the owner-actions menu, we will load the owner module resources into the application. From the previous statement, we can see why is Angular lazy loading important for Angular applications.

Routing for the Owner Module

Now, to enable navigation to the OwnerList component, we have to modify the owner-routing.module.ts:

import { NgModule } from '@angular/core';

import { RouterModule, Routes } from '@angular/router';

import { OwnerListComponent } from './owner-list/owner-list.component';

const routes: Routes = [

{ path:'list', component: OwnerListComponent }

];

@NgModule({

imports: [RouterModule.forChild(routes)],

exports: [RouterModule]

})

export class OwnerRoutingModule { }

With this setup, we are exposing our OwnerListComponent on the http://localhost:4200/owner/list endpoint. Moreover, we are using the RouterModule.forChild function and not the forRoot function. This is the case because we should use the forRoot function only in the root module of the application.

Now we have to modify the menu.component.html file:

<div class="collapse navbar-collapse" id="collapseNav" [collapse]="!isCollapsed" [isAnimated]="true">

<ul class="navbar-nav me-auto mb-2 mb-lg-0">

<li class="nav-item">

<a class="nav-link" [routerLink]="['/owner/list']" routerLinkActive="active"

[routerLinkActiveOptions]="{exact: true}"> Owner Actions </a>

</li>

<li class="nav-item">

<a class="nav-link" href="#">Account Actions </a>

</li>

</ul>

</div>

After all of these modifications, we can run our app and click the Owner Actions link. As soon as we do that, our new component will show up, and the link will get an active class style:

Now we know how to set up the routing for the child module, and for the component inside that module as well.

Subscription and Data Display

Let’s continue on.

When we navigate to the Owner Actions menu, we want to show all of the owners to the user. So that means when the owner component loads, the app automatically gets all the owners from the server.

We already have our Owner interface created (from the previous post) and we will use it here.

That said, let’s modify the OwnerListComponent file:

import { Component, OnInit } from '@angular/core';

import { Owner } from './../../_interfaces/owner.model';

import { OwnerRepositoryService } from './../../shared/services/owner-repository.service';

@Component({

selector: 'app-owner-list',

templateUrl: './owner-list.component.html',

styleUrls: ['./owner-list.component.css']

})

export class OwnerListComponent implements OnInit {

owners: Owner[];

constructor(private repository: OwnerRepositoryService) { }

ngOnInit(): void {

this.getAllOwners();

}

private getAllOwners = () => {

const apiAddress: string = 'api/owner';

this.repository.getOwners(apiAddress)

.subscribe(own => {

this.owners = own;

})

}

}

We have the owners property with the and it is of the Owner array type. Next, we execute the subscribe function, which is going to populate that property with all the owners from the server. Using that owners property to create our HTML page is what we aim for.

To accomplish that, let’s modify the HTML component:

<div class="row">

<div class="offset-10 col-md-2 mt-2"> <a href="#">Create owner</a> </div>

</div> <br>

<div class="row">

<div class="col-md-12">

<div class="table-responsive">

<table class="table table-striped">

<thead>

<tr>

<th>Owner name</th>

<th>Owner address</th>

<th>Date of birth</th>

<th>Details</th>

<th>Update</th>

<th>Delete</th>

</tr>

</thead>

<tbody>

<tr *ngFor="let owner of owners">

<td>{{owner.name}}</td>

<td>{{owner.address}}</td>

<td>{{owner.dateOfBirth | date: 'dd/MM/yyyy'}}</td>

<td><button type="button" id="details" class="btn btn-primary">Details</button></td>

<td><button type="button" id="update" class="btn btn-success">Update</button></td>

<td><button type="button" id="delete" class="btn btn-danger">Delete</button></td>

</tr>

</tbody>

</table>

</div>

</div>

</div>

We could split this html file into two components (the parent component: OwnerList and the child component Owner). But because we didn’t explain how to use child components, which we’ll do in the next posts, we are going to leave it like this for now.

We use some basic Bootstrap classes to create a table showing the owner’s data. Inside that table, we loop over all the owners with the *ngFor directive. Then by using interpolation {{}}, we show owner properties on the page. For the dateOfBirth property, we are using just the Date pipe | date: 'dd/MM/yyyy' to format it the way we want to see it on a screen.

In our application, we are going to use the date format as MM/dd/yyyy, but here we are going to use dd/MM/yyyy just to demonstrate the way to change the format with pipes without too much effort.

Now, we can start our server app, which you can find on this GitHub repo. Once we start it, we can run our Angular app and navigate to the Owner Actions link:

Conclusion

By reading this post we have learned how to create a new module and what imports to use. Additionally, we’ve learned the way to configure Angular lazy loading and how it can help our application.

Also, now we know how to execute HTTP request with a subscription and display result data on the page, and the way to reformat our date when displaying it.

Angular Components and Project Preparation

 

Installation of the Angular CLI and Starting a New Project

First, we are going to install the Angular CLI (Angular Command Line Interface) which will help us a lot with the Angular project preparation and Angular project development overall.

To install Angular CLI, we need to open the command prompt (the best option is to open it as administrator) and use the install command:

npm install -g @angular/cli

If you already have the Angular CLI installed, you can check if you have the latest version:

ng --version

If you don’t have the latest version (13 for this article), you can uninstall it:

npm uninstall -g @angular/cli

npm cache clean --force

And after that, we can use the install command (mentioned above) to reinstall it.

After the installation completes, we are going to create a new project in the same command window:

ng new AccountOwnerClient --strict false

Two questions will appear. The first one is whether we want our project to have routing created, and the second one is about what kind of styling we want in our project. We are going to answer Yes (Y) for the first question, and (CSS – just hit enter) for the second one.

It will take some time to create the project.

After the creation process is over, we are going to open the project folder inside our editor. We will use Visual Studio Code.

Third-Party Libraries as Part Of Angular Project Preparation

We are going to use the ngx-bootstrap library (angular bootstrap) for styling, so let’s install it using the terminal window in the VS Code:

ng add ngx-bootstrap

After we start the installation, it will inform us that we are about to install the ngx-bootstrap@8.0.0 (in our case) package and whether we like to proceed. We are going to confirm that and finish the installation.

With this installation, we are installing both bootstrap and ngx-bootstrap, and also our package.json, angular.json, and app.module files will be updated:

✅️ Added "bootstrap

✅️ Added "ngx-bootstrap

UPDATE package.json (1140 bytes)

UPDATE angular.json (3160 bytes)

UPDATE src/app/app.module.ts (502 bytes)

At this point, we can try to run our app:

ng serve -o

With this command, we are going to run our app and also open it in a browser automatically (-0 flag).

If you get an error now (this is possible to happen due to a new ngx-bootstrap version), all you have to do is to open the angular.json file and modify the styles array:

"styles": [

"./node_modules/ngx-bootstrap/datepicker/bs-datepicker.css",

"./node_modules/bootstrap/dist/css/bootstrap.min.css",

"src/styles.css"

]

We have to modify the ngx-bootstrap path since it is wrong by default.

After this modification, we can run our app, and after a few seconds, we are going to see the initial page:

The next step is adding our components to the project.

Creating Angular Components

Let’s take some time to talk a bit about Angular. Angular is a framework for building SPA (Single Page Application) applications. Therefore, we are going to generate all of our pages inside one page. That is why we only have the index.html page inside the src folder. In the index.html file all content is going to be generated inside <app-root></app-root> selector, which comes from the app.component.ts file.

That said, let’s take a look inside the src/app/app.component.ts file:

import { Component } from '@angular/core';

@Component({

selector: 'app-root',

templateUrl: './app.component.html',

styleUrls: ['./app.component.css']

})

export class AppComponent {

title = 'AccountOwnerClient';

}

Every component must import Component from the @angular/core package. We will import more things when we need them. Also, we can notice the @Component decorator inside the code.

This is the place where we create our selector (it is the same as the app-root tag in the index.html file). Additionally, we are binding the HTML template for this component with the templateUrl and the CSS files with this component by using styleUrls. StyleUrls is an array of strings, comma-separated.

Lastly, we have the exported class for the component.

Now let’s take a look in the app.module.ts file, which is quite important for the Angular project preparation and for development at all :

import { NgModule } from '@angular/core';

import { BrowserModule } from '@angular/platform-browser';

import { AppRoutingModule } from './app-routing.module';

import { AppComponent } from './app.component';

import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

@NgModule({

declarations: [

AppComponent

],

imports: [

BrowserModule,

AppRoutingModule,

BrowserAnimationsModule

],

providers: [],

bootstrap: [AppComponent]

})

export class AppModule { }

In this file, we are going to import the necessary modules, components, and services. We are going to use the declarations array to import our components, and the imports array to import our modules. Also, we are going to use the providers array for registering our services.

Creating a New Angular Component

To create a new component named Home, let’s execute the required command:

ng g component home --skip-tests

With this command, we create the Home component with three files (.ts, .html, .css), and update the app.module file:

CREATE src/app/home/home.component.html (19 bytes)

CREATE src/app/home/home.component.ts (267 bytes)

CREATE src/app/home/home.component.css (0 bytes)

UPDATE src/app/app.module.ts (576 bytes)

Also, by adding the --skip-tests flag, we prevent creating the test file.

After the creation, we can inspect the Home component:

import { Component, OnInit } from '@angular/core';

@Component({

selector: 'app-home',

templateUrl: './home.component.html',

styleUrls: ['./home.component.css']

})

export class HomeComponent implements OnInit {

constructor() { }

ngOnInit(): void {

}

}

Here we import OnInit interface which defines the ngOnInit function. This function will execute any logic inside it as soon as the component initializes.

We can notice the constructor as well. The constructor is intended only for the injection of the service into the component. For any action that needs to be executed upon component initialization, we should use the ngOnInit function.

About App.Module

If we check the app.module.ts file, we will see that our new component is imported with our previous command:

import { NgModule } from '@angular/core';

import { BrowserModule } from '@angular/platform-browser';

import { AppRoutingModule } from './app-routing.module';

import { AppComponent } from './app.component';

import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

import { HomeComponent } from './home/home.component';

@NgModule({

declarations: [

AppComponent,

HomeComponent

],

imports: [

BrowserModule,

AppRoutingModule,

BrowserAnimationsModule

],

providers: [],

bootstrap: [AppComponent]

})

export class AppModule { }

So, as we can see, Angular CLI creates all of this for us.

Even though one module is enough for the entire application, we still want to create more modules.

Why?

Because it is easier to maintain the modules and also more modules give us the advantage of the lazy content loading. That means that our application will load only content related to that specific module we are pointing to, and not the entire application.

That said, let’s continue.

Additional Content in the Home Component

Let’s modify the home.component.ts file:

export class HomeComponent implements OnInit {

public homeText: string;

constructor() { }

ngOnInit(): void {

this.homeText = "WELCOME TO ACCOUNT-OWNER APPLICATION";

}

}

Then, let’s add a new class to the home.component.css file:

.homeText{

font-size: 35px;

color: red;

text-align: center;

position: relative;

top:30px;

text-shadow: 2px 2px 2px gray;

}

To continue, we are going to change the home.component.html file:

<p class="homeText">{{homeText}}</p>

Finally, let’s modify the app.component.html file, by removing all the content and adding a new one, just to test if this works:

<div class="container">

<div class="row">

<div class="col">

<app-home></app-home>

</div>

</div>

</div>

Now in the terminal, let’s type again ng serve -o and wait for the application to compile and run. We should see the welcome message on the screen from the Home component.

Conclusion

Right now we have a working component and an Angular application that we can run in our browser. But it is just the beginning. We have a long way ahead of us because there are still a lot of important Angular features to introduce to the project.

ASP.NET Core Web API – Post, Put, Delete

 

In the previous post, we have handled different GET requests with the help of a DTO object. In this post, we are going to create POST PUT DELETE requests and by doing so we are going to complete the server part (.NET Core part) of this series.

Let’s get into it.

Let’s get right into it.

Handling POST Request

Firstly, let’s modify the decoration attribute for the action method GetOwnerById in the Owner controller:

[HttpGet("{id}", Name = "OwnerById")]

With this modification, we are setting the name for the action. This name will come in handy in the action method for creating a new owner.

we use the model class just to fetch the data from the database, to return the result we need a DTO. It is the same for the create action. So, let’s create the OwnerForCreationDto class in the Entities/DataTransferObjects folder:

public class OwnerForCreationDto

{

[Required(ErrorMessage = "Name is required")]

[StringLength(60, ErrorMessage = "Name can't be longer than 60 characters")]

public string? Name { get; set; }

[Required(ErrorMessage = "Date of birth is required")]

public DateTime DateOfBirth { get; set; }

[Required(ErrorMessage = "Address is required")]

[StringLength(100, ErrorMessage = "Address cannot be loner then 100 characters")]

public string? Address { get; set; }

}

As you can see, we don’t have the Id and Accounts properties.

We are going to continue with the interface modification:

public interface IOwnerRepository : IRepositoryBase<Owner>

{

IEnumerable<Owner> GetAllOwners();

Owner GetOwnerById(Guid ownerId);

Owner GetOwnerWithDetails(Guid ownerId);

void CreateOwner(Owner owner);

}

After the interface modification, we are going to implement that interface:

public void CreateOwner(Owner owner)

{

Create(owner);

}

Before we modify the OwnerController, we have to create an additional mapping rule:

CreateMap<OwnerForCreationDto, Owner>();

Lastly, let’s modify the controller:

[HttpPost]

public IActionResult CreateOwner([FromBody]OwnerForCreationDto owner)

{

try

{

if (owner is null)

{

_logger.LogError("Owner object sent from client is null.");

return BadRequest("Owner object is null");

}

if (!ModelState.IsValid)

{

_logger.LogError("Invalid owner object sent from client.");

return BadRequest("Invalid model object");

}

var ownerEntity = _mapper.Map<Owner>(owner);

_repository.Owner.CreateOwner(ownerEntity);

_repository.Save();

var createdOwner = _mapper.Map<OwnerDto>(ownerEntity);

return CreatedAtRoute("OwnerById", new { id = createdOwner.Id }, createdOwner);

}

catch (Exception ex)

{

_logger.LogError($"Something went wrong inside CreateOwner action: {ex.Message}");

return StatusCode(500, "Internal server error");

}

}

Right now is a good time to test this code by sending the POST request by using Postman.

Code Explanation

Let’s talk a little bit about this code. The interface and the repository parts are pretty clear so we won’t talk about that. But the code in the controller contains several things worth mentioning.

The CreateOwner method has its own [HttpPost] decoration attribute, which restricts it to the POST requests. Furthermore, notice the owner parameter which comes from the client. We are not collecting it from Uri but from the request body. Thus the usage of the [FromBody] attribute. Also, the owner object is a complex type and because of that, we have to use [FromBody].

If we wanted to, we could explicitly mark the action to take this parameter from the Uri by decorating it with the [FromUri] attribute, though I wouldn’t recommend that at all due to the security reasons and complexity of the request.

Since the owner parameter comes from the client, it could happen that the client doesn’t send that parameter at all. As a result, we have to validate it against the reference type’s default value, which is null.

Further down the code, you can notice this type of validation: if(!ModelState.IsValid). If you look at the owner model properties: Name, Address, and DateOfBirth, you will notice that all of them are decorated with Validation Attributes. If for some reason validation fails, the ModelState.IsValid will return false as a result, signaling that something is wrong with the creation DTO object. Otherwise, it will return true which means that values in all the properties are valid.

We have two map actions as well. The first one is from the OwnerForCreationDto type to the Owner type because we accept the OwnerForCreationDto object from the client and we have to use the Owner object for the create action. The second map action is from the Owner type to the OwnerDto type, which is a type we return as a result.

The last thing to mention is this part of the code:

CreatedAtRoute("OwnerById", new { id = owner.Id}, owner);

CreatedAtRoute will return a status code 201, which stands for Created as explained in our post: The HTTP Reference. Also, it will populate the body of the response with the new owner object as well as the Location attribute within the response header with the address to retrieve that owner. We need to provide the name of the action, where we can retrieve the created entity:

If we copy this address and paste it in Postman, once we send the GET request, we are going to get a newly created owner object.

Handling PUT Request

Excellent.

Let’s continue with the PUT request, to update the owner entity.

First, we are going to add an additional DTO class:

public class OwnerForUpdateDto

{

[Required(ErrorMessage = "Name is required")]

[StringLength(60, ErrorMessage = "Name can't be longer than 60 characters")]

public string Name { get; set; }

[Required(ErrorMessage = "Date of birth is required")]

public DateTime DateOfBirth { get; set; }

[Required(ErrorMessage = "Address is required")]

[StringLength(100, ErrorMessage = "Address cannot be loner then 100 characters")]

public string Address { get; set; }

}

We did the same thing as with the OwnerForCreationDto class. Even though this class looks the same as the OwnerForCreationDto, they are not the same. First of all, they have a semantical difference, this one is for update action and the previous one is for creation. Additionally, the validation rules that apply for the creation of DTO don’t have to be the same for the update DTO. Therefore, it is always a good practice to separate those.

One more thing, if you want to remove the code duplication from the OwnerForCreationDto and OwnerForUpdateDto, you can create an additional abstract class, extract properties to it and then just force these classes to inherit from the abstract class. Due to the sake of simplicity, we won’t do that now.

After that, we have to create a new map rule:

CreateMap<OwnerForUpdateDto, Owner>();

Then, let’s change the interface:

public interface IOwnerRepository : IRepositoryBase<Owner>

{

IEnumerable<Owner> GetAllOwners();

Owner GetOwnerById(Guid ownerId);

Owner GetOwnerWithDetails(Guid ownerId);

void CreateOwner(Owner owner);

void UpdateOwner(Owner owner);

}

Of course, we have to modify the OwnerRepository.cs:

public void UpdateOwner(Owner owner)

{

Update(owner);

}

Finally, alter the OwnerController:

[HttpPut("{id}")]

public IActionResult UpdateOwner(Guid id, [FromBody]OwnerForUpdateDto owner)

{

try

{

if (owner is null)

{

_logger.LogError("Owner object sent from client is null.");

return BadRequest("Owner object is null");

}

if (!ModelState.IsValid)

{

_logger.LogError("Invalid owner object sent from client.");

return BadRequest("Invalid model object");

}

var ownerEntity = _repository.Owner.GetOwnerById(id);

if (ownerEntity is null)

{

_logger.LogError($"Owner with id: {id}, hasn't been found in db.");

return NotFound();

}

_mapper.Map(owner, ownerEntity);

_repository.Owner.UpdateOwner(ownerEntity);

_repository.Save();

return NoContent();

}

catch (Exception ex)

{

_logger.LogError($"Something went wrong inside UpdateOwner action: {ex.Message}");

return StatusCode(500, "Internal server error");

}

}

As you may have noticed, the action method is decorated with the [HttpPut] attribute. Furthermore, it receives two parameters: id of the entity we want to update and the entity with the updated fields, taken from the request body. The rest of the code is pretty simple. After the validation, we are pulling the owner from the database and executing the update of that owner. Finally, we return NoContent which stands for the status code 204:

You can read more about Update actions in ASP.NET Core with EF Core to get a better picture of how things are done behind the scene. It could be very useful to upgrade quality of the update actions.

Handling DELETE Request

For the Delete request, we should just follow these steps:

Interface:

public interface IOwnerRepository : IRepositoryBase<Owner>

{

IEnumerable<Owner> GetAllOwners();

Owner GetOwnerById(Guid ownerId);

Owner GetOwnerWithDetails(Guid ownerId);

void CreateOwner(Owner owner);

void UpdateOwner(Owner owner);

void DeleteOwner(Owner owner);

}

OwnerRepository:

public void DeleteOwner(Owner owner)

{

Delete(owner);

}

OwnerController:

[HttpDelete("{id}")]

public IActionResult DeleteOwner(Guid id)

{

try

{

var owner = _repository.Owner.GetOwnerById(id);

if(owner == null)

{

_logger.LogError($"Owner with id: {id}, hasn't been found in db.");

return NotFound();

}

_repository.Owner.DeleteOwner(owner);

_repository.Save();

return NoContent();

}

catch (Exception ex)

{

_logger.LogError($"Something went wrong inside DeleteOwner action: {ex.Message}");

return StatusCode(500, "Internal server error");

}

}

Let’s handle one more thing. If you try to delete the owner that has accounts, you are going to get 500 internal errors because we didn’t allow cascade delete in our database configuration. What we want is to return a BadRequest. So, to do that let’s make a couple of modifications.

Modify the IAccountRepository interface:

using Entities.Models;

namespace Contracts

{

public interface IAccountRepository

{

IEnumerable<Account> AccountsByOwner(Guid ownerId);

}

}

Then modify the AccountRepository file by adding one new method:

public IEnumerable<Account> AccountsByOwner(Guid ownerId)

{

return FindByCondition(a => a.OwnerId.Equals(ownerId)).ToList();

}

Finally, modify the DeleteOwner action in the OwnerController by adding one more validation before deleting the owner:

if(_repository.Account.AccountsByOwner(id).Any())

{

_logger.LogError($"Cannot delete owner with id: {id}. It has related accounts. Delete those accounts first");

return BadRequest("Cannot delete owner. It has related accounts. Delete those accounts first");

}

So, that is it. Send the Delete request from Postman and see the result. The owner object should be deleted from the database.

We have created these actions that use Repository Pattern logic synchronously but it could be done asynchronously as well. If you want to learn how to do that you can visit Implementing Async Repository in .NET Core. Although we strongly recommend finishing all the parts from this series for an easier understanding of the project’s business logic.

Also, in all these actions we are using try-catch blocks to handle our errors. You can do that in a more readable and maintainable way by introducing the Global Error Handling feature.

Conclusion

Now that you know all of this, try to repeat all the actions but for the Account entity. Because nothing beats the practice, doesn’t it? 😉

With all this code in place, we have a working web API that covers all the features for handling the CRUD operations.

By reading this post you’ve learned:

• The way to handle the POST request
• How to handle PUT request
• How to write better and more reusable code
• And the way to handle DELETE request

Thank you for reading and I hope you found something useful in it.