Edition 0 Updated to asp. Net core 0

Additional resources 
•
Unit & Integration testing
on the eShopOnContainers 
https://github.com/dotnet-architecture/eShopOnContainers/wiki/Unit-and-integration-testing
 
•
Load testing
on the eShopOnContainers 
https://github.com/dotnet-architecture/eShopOnContainers/wiki/Load-testing
 
Implement background tasks in microservices with 
IHostedService and the BackgroundService class 
Background tasks and scheduled jobs are something you might need to use in any application, 
whether or not it follows the microservices architecture pattern. The difference when using a 
microservices architecture is that you can implement the background task in a separate 
process/container for hosting so you can scale it down/up based on your need. 

---

158 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
From a generic point of view, in .NET we called these type of tasks 
Hosted Services
, because they are 
services/logic that you host within your host/application/microservice. Note that in this case, the 
hosted service simply means a class with the background task logic. 
Since .NET Core 2.0, the framework provides a new interface named 
IHostedService
 helping you to 
easily implement hosted services. The basic idea is that you can register multiple background tasks 
(hosted services) that run in the background while your web host or host is running, as shown in the 
image 6-26. 
Figure 6-26. Using IHostedService in a WebHost vs. a Host 
ASP.NET Core 1.x and 2.x support 
IWebHost
for background processes in web apps. .NET Core 2.1 and 
later versions support 
IHost
for background processes with plain console apps. Note the difference 
made between 
WebHost
and 
Host
. 
A 
WebHost
(base class implementing 
IWebHost
) in ASP.NET Core 2.0 is the infrastructure artifact you 
use to provide HTTP server features to your process, such as when you’re implementing an MVC web 
app or Web API service. It provides all the new infrastructure goodness in ASP.NET Core, enabling you 
to use dependency injection, insert middlewares in the request pipeline, and similar. The 
WebHost
uses 
these very same 
IHostedServices
for background tasks. 
A 
Host
(base class implementing 
IHost
) was introduced in .NET Core 2.1. Basically, a 
Host
allows you 
to have a similar infrastructure than what you have with 
WebHost
(dependency injection, hosted 
services, etc.), but in this case, you just want to have a simple and lighter process as the host, with 
nothing related to MVC, Web API or HTTP server features. 
Therefore, you can choose and either create a specialized host-process with 
IHost
to handle the 
hosted services and nothing else, such a microservice made just for hosting the 
IHostedServices
, or 
you can alternatively extend an existing ASP.NET Core 
WebHost
, such as an existing ASP.NET Core Web 
API or MVC app. 

---

159 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Each approach has pros and cons depending on your business and scalability needs. The bottom line 
is basically that if your background tasks have nothing to do with HTTP (
IWebHost
) you should use 
IHost
.