DEV Community: Luciano Azevedo

Your first background job in .NET with NexJob

Luciano Azevedo — Tue, 13 Oct 2026 12:57:29 +0000

Your first background job in .NET with NexJob

Sooner or later a web app needs to do something that should not block the request: send an e-mail, resize an image, call a slow API. This post builds the smallest possible background job in .NET 8 and runs it. No database, no extra services, about five minutes.

What you need

The .NET 8 SDK
A terminal

1. A project

dotnet new worker -n MyJobs
cd MyJobs
dotnet add package NexJob

A worker service is the simplest host. Everything below works the same inside an ASP.NET Core app.

2. Register NexJob

Two lines in Program.cs: one to add NexJob, one to let it find your job classes.

using NexJob;

var host = Host.CreateDefaultBuilder(args)
    .ConfigureServices(services =>
    {
        services.AddNexJob();
        services.AddNexJobJobs(typeof(Program).Assembly);
    })
    .Build();

Call AddNexJob() once. Calling it twice registers the background services twice.

3. Write the job

A job is a class with one method. Implement IJob when the work needs no input.

public sealed class HelloJob : IJob
{
    public Task ExecuteAsync(CancellationToken ct)
    {
        Console.WriteLine($"Hello at {DateTimeOffset.UtcNow:O}");
        return Task.CompletedTask;
    }
}

Two things worth knowing right away:

NexJob builds the job from your dependency injection container, so constructor injection works like anywhere else in .NET.
The CancellationToken is yours to honor. When the host shuts down, it is how the job finds out.

4. Enqueue it

Ask the container for IScheduler and enqueue the job.

await host.StartAsync();

var scheduler = host.Services.GetRequiredService<IScheduler>();
await scheduler.EnqueueAsync<HelloJob>();

await host.WaitForShutdownAsync();

5. Run it

dotnet run

Hello at 2026-10-13T12:33:27.9831829+00:00

That is the whole loop. The job was stored, picked up by a worker running inside your process, and executed. There is no separate worker process to deploy.

A job that takes input

Most real jobs need data. Implement IJob<T> and use a record for the input: it serializes cleanly and cannot change after it is enqueued.

public sealed record SendWelcomeEmailInput(string Email, string UserName);

public sealed class SendWelcomeEmailJob : IJob<SendWelcomeEmailInput>
{
    private readonly IEmailService _email;

    public SendWelcomeEmailJob(IEmailService email) => _email = email;

    public async Task ExecuteAsync(SendWelcomeEmailInput input, CancellationToken ct)
        => await _email.SendAsync(input.Email, $"Welcome, {input.UserName}!", ct);
}

await scheduler.EnqueueAsync<SendWelcomeEmailJob, SendWelcomeEmailInput>(
    new SendWelcomeEmailInput("user@example.com", "Jane"));

What happens if the process stops?

With the default storage, jobs live in memory and are gone when the process exits. That is fine for trying things out and for tests. For anything real, add a database provider:

dotnet add package NexJob.Postgres

services.AddNexJobPostgres("Host=localhost;Database=nexjob;Username=postgres;Password=secret");
services.AddNexJob();

Register the provider before AddNexJob(), so it replaces the in-memory default. SQL Server, Redis and MongoDB providers exist too.

Where to go next

Retries and what happens when a job keeps failing
Delays, recurring jobs and deadlines
Seeing what your jobs are doing (the next posts in this series)

Source and samples: https://github.com/oluciano/NexJob
Documentation: https://oluciano.github.io/NexJob/

🏗️ Aplicando Adapter e Decorator Patterns com Injeção de Dependência no C#

Luciano Azevedo — Sun, 02 Feb 2025 22:00:25 +0000

Ao desenvolver software, muitas vezes precisamos integrar sistemas legados e adicionar funcionalidades sem modificar diretamente o código existente. Para isso, podemos usar padrões de design como Adapter e Decorator, que nos ajudam a estruturar o código de forma modular e reutilizável.

Neste artigo, vamos explorar como usar esses padrões no C# com injeção de dependência (DI) e a biblioteca Scrutor para simplificar o registro dos decorators.

🎯 Cenário do Problema

Imagine que temos um serviço legado que processa pagamentos, mas ele não segue a interface moderna que queremos usar em nosso sistema. Além disso, queremos adicionar logs ao processamento de pagamentos sem modificar diretamente o serviço existente.

Vamos resolver isso combinando Adapter e Decorator!

📌 Passo 1: Definindo a Interface Padrão

Criamos a interface IPaymentProcessor para definir um contrato padrão para processadores de pagamento:

public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount);
}

Essa interface será usada tanto pelo Adapter quanto pelo Decorator.

📌 Passo 2: Criando o Serviço Legado

Nosso serviço legado (LegacyPaymentService) não segue a interface moderna. Ele espera um string em vez de um decimal:

public sealed class LegacyPaymentService
{
    public void MakePayment(string amount)
    {
        Console.WriteLine($"Processing payment of {amount} via legacy system.");
    }
}

Para integrá-lo ao sistema moderno, usaremos o Adapter Pattern.

📌 Passo 3: Criando o Adapter

O Adapter faz a conversão entre IPaymentProcessor e LegacyPaymentService:

public sealed class PaymentAdapter : IPaymentProcessor
{
    private readonly LegacyPaymentService _legacyPaymentService;

    public PaymentAdapter(LegacyPaymentService legacyPaymentService)
    {
        _legacyPaymentService = legacyPaymentService;
    }

    public void ProcessPayment(decimal amount)
    {
        string amountString = amount.ToString("F2");
        _legacyPaymentService.MakePayment(amountString);
    }
}

Agora podemos usar PaymentAdapter em qualquer lugar que espera IPaymentProcessor.

📌 Passo 4: Criando o Decorator para Logging

Agora adicionamos um Decorator (LoggingDecorator) para registrar logs sempre que um pagamento for processado:

using Microsoft.Extensions.Logging;

public class LoggingDecorator : IPaymentProcessor
{
    private readonly IPaymentProcessor _innerProcessor;
    private readonly ILogger<LoggingDecorator> _logger;

    public LoggingDecorator(IPaymentProcessor innerProcessor, ILogger<LoggingDecorator> logger)
    {
        _innerProcessor = innerProcessor;
        _logger = logger;
    }

    public void ProcessPayment(decimal amount)
    {
        _logger.LogInformation($"Iniciando processamento do pagamento de {amount:C}");
        _innerProcessor.ProcessPayment(amount);
        _logger.LogInformation($"Pagamento de {amount:C} processado com sucesso.");
    }
}

Esse Decorator adiciona logs antes e depois da chamada real ao PaymentProcessor, sem modificar sua implementação.

📌 Passo 5: Criando o Worker Service

Para simular um sistema em execução contínua, criamos um Worker Service que chama IPaymentProcessor:

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using System;
using System.Threading;
using System.Threading.Tasks;

public class PaymentWorker : BackgroundService
{
    private readonly ILogger<PaymentWorker> _logger;
    private readonly IPaymentProcessor _paymentProcessor;

    public PaymentWorker(ILogger<PaymentWorker> logger, IPaymentProcessor paymentProcessor)
    {
        _logger = logger;
        _paymentProcessor = paymentProcessor;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _logger.LogInformation("Iniciando ciclo do Worker...");

            _paymentProcessor.ProcessPayment(100.50m); // Simulando pagamento

            await Task.Delay(5000, stoppingToken); // Executa a cada 5 segundos
        }
    }
}

📌 Passo 6: Configurando a Injeção de Dependência (DI) com Scrutor

Podemos usar a biblioteca Scrutor para simplificar o registro do Decorator.
Primeiro, instalamos a dependência via NuGet:

dotnet add package Scrutor

Agora, configuramos os serviços no Program.cs:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Scrutor;

class Program
{
    static void Main(string[] args)
    {
        var host = Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                services.AddSingleton<LegacyPaymentService>(); // Serviço legado

                // Registra o Adapter
                services.AddSingleton<PaymentAdapter>(); 
                services.AddSingleton<IPaymentProcessor>(provider => 
                    provider.GetRequiredService<PaymentAdapter>());

                // Adiciona o LoggingDecorator automaticamente com Scrutor
                services.Decorate<IPaymentProcessor, LoggingDecorator>();

                // Registra o Worker Service
                services.AddHostedService<PaymentWorker>(); 
                services.AddLogging(); 
            })
            .Build();

        host.Run();
    }
}

📌 Estrutura de Pastas

Aqui está a estrutura do projeto para manter tudo organizado:

📂 PaymentProcessorApp
│── 📂 Adapters
│ └── PaymentAdapter.cs
│── 📂 Decorators
│ └── LoggingDecorator.cs
│── 📂 Interfaces
│ └── IPaymentProcessor.cs
│── 📂 Services
│ └── LegacyPaymentService.cs
│── 📂 Workers
│ └── PaymentWorker.cs
│── Program.cs
│── PaymentProcessorApp.csproj

🚀 Benefícios dessa Abordagem

✅ Código modular e reutilizável → Podemos adicionar novos IPaymentProcessor ou decorators sem alterar a implementação principal.
✅ Extensibilidade → Podemos criar mais decorators, como um validador ou auditoria.
✅ Baixo acoplamento → Usando DI e Scrutor, evitamos dependências rígidas.
✅ Facilidade de Testes → Podemos testar LoggingDecorator separadamente.

Essa abordagem combina Adapter e Decorator Patterns com Injeção de Dependência, mantendo o código limpo, flexível e escalável.

Se você gostou, deixe um comentário ou compartilhe! 🚀🔥

Adapter Pattern em C# com Injeção de Dependência e Worker Service

Luciano Azevedo — Sun, 02 Feb 2025 20:36:38 +0000

🚀 Aplicando o Adapter Pattern em C# com Injeção de Dependência e Worker Service

📌 Introdução

Ao trabalhar com sistemas legados, é comum encontrar APIs ou serviços que não seguem as interfaces modernas do nosso código. Em vez de modificar diretamente esses sistemas, podemos usar o Adapter Pattern para fazer a integração de forma elegante.

Neste artigo, vou mostrar como implementar o Adapter Pattern em C#, usando Injeção de Dependência (DI) e um Worker Service para simular um processo contínuo.

🎯 O que é o Adapter Pattern?

O Adapter Pattern é um padrão estrutural que permite que objetos com interfaces incompatíveis trabalhem juntos. Ele age como um intermediário, convertendo a interface de uma classe para outra esperada pelo sistema.

📌 Quando usar?

✅ Quando precisamos integrar APIs ou bibliotecas legadas que não podem ser alteradas.
✅ Quando queremos manter um código desacoplado e flexível.
✅ Quando temos diferentes implementações que precisam seguir um mesmo contrato.

🛠️ Implementação

Vamos construir um exemplo onde temos um sistema de pagamentos legados e queremos integrá-lo a um Worker Service que processa pagamentos periodicamente.

🏗️ 1️⃣ Criamos a interface moderna IPaymentProcessor

public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount);
}

🏗️ 2️⃣ Criamos o serviço legado LegacyPaymentService

Este é um serviço que já existe e que queremos reutilizar, mas ele usa uma interface diferente.

public sealed class LegacyPaymentService
{
    public void MakePayment(string amount)
    {
        Console.WriteLine($"Processing payment of {amount} via legacy system.");
    }
}

🏗️ 3️⃣ Criamos o Adapter PaymentAdapter

Aqui adaptamos LegacyPaymentService para seguir a interface IPaymentProcessor.

public sealed class PaymentAdapter : IPaymentProcessor
{
    private readonly LegacyPaymentService _legacyPaymentService;

    public PaymentAdapter(LegacyPaymentService legacyPaymentService)
    {
        _legacyPaymentService = legacyPaymentService;
    }

    public void ProcessPayment(decimal amount)
    {
        string amountString = amount.ToString("F2");
        _legacyPaymentService.MakePayment(amountString);
    }
}

🏗️ 4️⃣ Criamos o Worker Service PaymentWorker

Nosso Worker será responsável por chamar o IPaymentProcessor periodicamente.

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using System;
using System.Threading;
using System.Threading.Tasks;

public class PaymentWorker : BackgroundService
{
    private readonly ILogger<PaymentWorker> _logger;
    private readonly IPaymentProcessor _paymentProcessor;

    public PaymentWorker(ILogger<PaymentWorker> logger, IPaymentProcessor paymentProcessor)
    {
        _logger = logger;
        _paymentProcessor = paymentProcessor;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _logger.LogInformation("Iniciando processamento de pagamento...");

            _paymentProcessor.ProcessPayment(100.50m); // Simulando pagamento de R$100,50

            _logger.LogInformation("Pagamento processado com sucesso!");

            await Task.Delay(5000, stoppingToken); // Executa a cada 5 segundos
        }
    }
}

🏗️ 5️⃣ Configuramos a Injeção de Dependência no Host

Agora precisamos configurar os serviços no Host do Worker Service.

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

class Program
{
    static void Main(string[] args)
    {
        var host = Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                services.AddSingleton<LegacyPaymentService>(); // Serviço legado
                services.AddSingleton<IPaymentProcessor, PaymentAdapter>(); // Adapter
                services.AddHostedService<PaymentWorker>(); // Worker Service
                services.AddLogging(); // Logs
            })
            .Build();

        host.Run();
    }
}

✅ O que aprendemos?

✔ Como usar o Adapter Pattern para conectar serviços legados a um código moderno.
✔ Como estruturar Injeção de Dependência (DI) para desacoplar o código.
✔ Como criar um Worker Service que processa tarefas periodicamente.

🚀 Conclusão

O Adapter Pattern é uma solução poderosa para integrar serviços sem alterar o código legado. Combinado com Injeção de Dependência e Worker Services, ele nos permite construir sistemas escaláveis e bem estruturados.

E você? Já usou esse padrão em algum projeto? Deixe um comentário! 🚀