DEV Community: Rodrigo Schemes

🎮 Singleton e Concorrência em C# — Um Joguinho pra Aprender de Verdade

Rodrigo Schemes — Tue, 10 Jun 2025 01:41:13 +0000

Fiz esse exemplo pra entender melhor como o padrão Singleton funciona na prática e como lidar com concorrência em C#. A ideia foi criar uma simulação de um jogo onde vários jogadores disputam uma pontuação limitada. No caminho, explorei técnicas de sincronização e execução paralela.

🔄 O que é Singleton, afinal?

O Singleton é um padrão de projeto que garante que uma classe tenha apenas uma instância durante toda a execução do programa.

Por que usar isso?

É útil quando precisamos de um ponto centralizado de controle, como um serviço de log, um gerenciador de configuração ou — no nosso caso — uma pontuação global.
Evita instanciar objetos repetidamente sem necessidade.
Garante que todo mundo (todas as threads, inclusive) estejam olhando pro mesmo objeto.

No meu código usei Lazy<T> pra deixar isso thread-safe e garantir que a instância só seja criada quando for realmente usada.

public sealed class PlacarGlobal
{
    private static readonly Lazy<GlobalScore> _instancia = new(() => new PlacarGlobal());
    public static PlacarGlobal Instancia => _instancia.Value;

    private PlacarGlobal() { }
}

🕹️ O jogo: como funciona?

Temos 500 pontos no total.
5 jogadores jogam ao mesmo tempo, cada um numa thread (ou Task).
A cada jogada, o jogador tenta pegar entre 1 e 10 pontos aleatoriamente.
Quando os pontos acabam, o jogo termina e mostramos o ranking final.

⚙️ Como fiz funcionar direitinho (sem bugs de concorrência)

1. `lock` para proteger a pontuação

Como todos os jogadores acessam e alteram os mesmos dados (pontuação total e placar), usei um lock pra evitar bagunça:

lock (_lock)
{
    // Acesso seguro
}

Isso garante que só uma thread por vez consiga pegar pontos.

2. Um cuidado com o `Random`

Se você usar new Random() direto em várias threads, pode acabar com números repetidos. Resolvi isso gerando a semente com Guid.NewGuid().GetHashCode(). Assim cada thread tem um gerador único:

var rng = new Random(Guid.NewGuid().GetHashCode());

3. Execução concorrente com `Task.Run`

Cada jogador roda numa Task, e eu espero todas terminarem com Task.WhenAll. Simples e eficiente.

var tasks = new List<Task>();

for (var i = 1; i <= 5; i++)
{
    var jogadorId = i;
    tasks.Add(Task.Run(async () => {
        while (ObterPontos(jogadorId))
            await Task.Delay(rng.Next(100, 500));
    }));
}

await Task.WhenAll(tasks);

4. Ranking final com `ConcurrentDictionary`

Usei um ConcurrentDictionary pra armazenar o placar de cada jogador. Ele já é thread-safe, então não precisei de mais lock pra isso.

🏁 Resultado típico

### Iniciando partida! ###
### Jogador 1 pegou 8 pontos. Restantes: 492 ###
...
### Jogador 3 terminou. ###

### Ranking Final: ###
#1 - Jogador 4 : 142 pontos
#2 - Jogador 2 : 129 pontos
#3 - Jogador 1 : 113 pontos
#4 - Jogador 5 : 74 pontos
#5 - Jogador 3 : 42 pontos

### Pontos distribuídos: 500/500 ###

💭 O que eu aprendi com isso

Singleton com Lazy<T> é super simples e seguro.
Concorrência em C# não precisa ser um bicho de sete cabeças se você usar lock e Task com cuidado.
E dá pra se divertir criando um joguinho simples e ver os conceitos funcionando na prática.

Se quiser, dá pra adaptar esse mesmo código pra outras situações onde vários processos disputam um recurso limitado.

🔗 Código-fonte no GitHub

Todo o código apresentado neste artigo está disponível no repositório:

👉 github.com/rodrigo-schemes/csharp-designpatterns

Sinta-se à vontade para clonar, estudar e até contribuir com sugestões ou melhorias. Esse projeto faz parte de uma série voltada para estudo e prática de Design Patterns com C#.

Decorator Pattern com Scrutor no Asp.Net Core

Rodrigo Schemes — Wed, 20 Sep 2023 19:47:41 +0000

Introdução

Uma das vantagens do ASP.NET Core é a sua capacidade de usar injeção de dependência para gerenciar serviços e componentes. No entanto, às vezes você pode precisar adicionar funcionalidades adicionais a esses serviços sem modificar seu código. É aí que o Decorator Pattern entra em jogo, e uma ótima maneira de implementá-lo é usando a biblioteca Scrutor.

Decorator Pattern

O Decorator Pattern é um padrão de design estrutural que permite adicionar comportamento adicional a um objeto existente, sem modificar sua estrutura. Isso é feito criando classes decoradoras que envolvem o objeto original e adicionam as funcionalidades desejadas.

Scrutor

O Scrutor é uma biblioteca para facilitar a implementação do Decorator Pattern ao injetar serviços em tempo de execução. Ele fornece uma maneira simples e limpa de adicionar funcionalidades a serviços existentes.

Implementando o Decorator Pattern com Scrutor

Vamos dar uma olhada em como implementar o Decorator Pattern com o Scrutor em um exemplo prático.

Suponha que você tenha um repositório IClienteRepositorio que realiza operações relacionadas a Clientes em sua API. Você deseja adicionar uma camada de cache a esse serviço sem modificar seu código existente.

1. Crie uma Interface do seu Repositório de Clientes: Essa interface é usada para representar um repositório de clientes, onde você pode buscar um cliente por seu ID.

public interface IClienteRepositorio
{
   Task<Cliente?> ObterPorIdAsync(int id);
}

2. Implemente a Interface do Repositório: Esta classe ClienteRepositorio implementa a interface IClienteRepositorio e fornece uma implementação para o método ObterPorIdAsync, que busca um cliente pelo seu ID em um contexto de banco de dados.

   public class ClienteRepositorio : IClienteRepositorio
   {
       private readonly AppDbContexto _appDbContexto;

       public ClienteRepositorio(AppDbContexto appDbContexto)
       {
           _appDbContexto = appDbContexto;
       }

       public async Task<Cliente?> ObterPorIdAsync(int id)
       {
           return await _appDbContexto
               .Set<Cliente>()
               .FirstOrDefaultAsync(cliente => cliente.ClienteId == id);
       }
   }

3. Crie a Classe do Decorator: Essa classe será a implementação do Cache. Ela deverá implementar a interface original do repositório de Clientes. Para simplificar o exemplo, vou utilizar o próprio serviço de Cache em memória do Asp.Net Core, o IMemoryCache

public class ClienteCacheRepositorio : IClienteRepositorio
{
    private readonly IClienteRepositorio _clienteRepositorio;
    private readonly IMemoryCache _memoryCache;

    public ClienteCacheRepositorio(IClienteRepositorio clienteRepositorio, 
        IMemoryCache memoryCache)
    {
        _clienteRepositorio = clienteRepositorio;
        _memoryCache = memoryCache;
    }

    public async Task<Cliente?> ObterPorIdAsync(int id)
    {
        var chave = $"cliente-{id}";

        return await _memoryCache.GetOrCreateAsync(chave, async cacheEntry =>
        {
            cacheEntry.SetAbsoluteExpiration(TimeSpan.FromMinutes(5));
            return await _clienteRepositorio.ObterPorIdAsync(id);
        });
    }
}

4. Instale o pacote Scrutor: você pode usar o gerenciador de pacotes NuGet com o seguinte comando: dotnet add package Scrutor.

5. Configure a Injeção de Dependência com o Scrutor: No Program.cs, configure a injeção de dependência para usar a classe do Decorator quando o IClienteRepositorio for solicitado.

builder.Services.AddMemoryCache();
builder.Services.AddScoped<IClienteRepositorio, ClienteRepositorio>();
builder.Services.Decorate<IClienteRepositorio, ClienteCacheRepositorio>();

Testando a implementação

Podemos validar o funcionamento do padrão Decorator com o Scrutor através do Debug. Se colocarmos um breakpoint na implementação do método ObterPorIdAsync, ele será executado apenas na primeira vez. Na segunda chamada, será utilizado o Memory Cache.

Podemos verificar o resultado através do tempo de resposta no Postman. Na primeira chamada da API, obtemos o cliente com o código "1". O tempo de resposta foi de 413 ms.

Na segunda chamada, podemos perceber a diferença no tempo de resposta, que foi de 10 ms, pois ele estava utilizando o cache de memória.

Conclusão

O Decorator Pattern é uma ferramenta poderosa para adicionar funcionalidades a objetos sem modificar seu código existente. Com o Scrutor em ASP.NET Core, você pode implementar facilmente o padrão Decorator ao injetar serviços em tempo de execução. Isso permite que você mantenha seu código limpo, modular e facilmente extensível.

Em resumo, os benefícios do Decorator Pattern são:

Flexibilidade: Permite adicionar funcionalidades extras a objetos sem modificar seu código original.
Manutenção Simples: Facilita a manutenção e evita classes excessivamente complexas.
Composição Dinâmica: Permite combinar funcionalidades de maneira flexível.
Reutilização de Código: Os decoradores podem ser reutilizados em diferentes partes do sistema.
Segregação de Responsabilidades: Mantém as classes com responsabilidades únicas.
Adere aos Princípios SOLID: Segue princípios de design de software sólidos.
Escalabilidade: Facilita a adição de novas funcionalidades sem alterar o código existente.

Referências

CI/CD ASP.NET Core com GitHub Actions e Azure

Rodrigo Schemes — Sun, 10 Sep 2023 00:53:53 +0000

Introdução

A implantação contínua (CI/CD) é uma prática essencial no desenvolvimento de software moderno. Ela permite automatizar o processo de construção, teste e implantação de aplicativos, garantindo atualizações rápidas e confiáveis. Neste artigo, vamos explorar como configurar um pipeline de CI/CD para um aplicativo ASP.NET Core, usando o GitHub Actions e implantando-o no Serviço de Aplicativo do Azure.

O que é o GitHub Actions?

O GitHub Actions é um serviço de automação oferecido pelo GitHub para ajudar os desenvolvedores a automatizar seus fluxos de trabalho de desenvolvimento de software. Ele permite que você crie, teste e implante seu código diretamente no GitHub. O melhor de tudo é que o GitHub Actions é gratuito para repositórios públicos e oferece uma generosa quantidade de minutos de execução para repositórios privados.

Pré-requisitos

Antes de começarmos, certifique-se de ter o seguinte:

Uma conta no GitHub.
Um repositório contendo um aplicativo ASP.NET Core.
Uma conta no Azure com acesso para criar um Serviço de Aplicativo.

Configurando o Pipeline

A seguir, veremos como configurar um pipeline de CI/CD para uma aplicação ASP.NET Core usando o GitHub Actions e implantá-la no Serviço de Aplicativo do Azure.

Etapa 1: Adicione um arquivo de configuração para o GitHub Actions

Acesse o seu repositório no GitHub.
No menu superior do seu repositório, clique na guia "Actions".
Na página "Actions", você verá uma opção chamada "Set up a workflow yourself" no lado direito. Clique nela.
Você será direcionado para um editor de código. Substitua todo o conteúdo por este código YAML de exemplo:

name: Publish

on:
  workflow_dispatch:
  push:
    branches:
    - main

env:
  AZURE_WEBAPP_NAME: exemplo-api

jobs:
  publish:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '7.0.x'

      - name: Restore
        run: dotnet restore ./Exemplo/Exemplo.sln

      - name: Build
        run: dotnet build ./Exemplo/Exemplo.sln --configuration Release --no-restore

      - name: Publish
        run: dotnet publish ./Exemplo/Exemplo.sln --configuration Release --no-build --property PublishDir=${{env.DOTNET_ROOT}}/myapp

      - name: Deployment
        uses: azure/webapps-deploy@v2
        with:
          app-name: ${{ env.AZURE_WEBAPP_NAME }}
          publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
          package: ${{env.DOTNET_ROOT}}/myapp

Etapa 2: Configure o ambiente de implantação no Azure

No Portal do Azure, crie um Serviço de Aplicativo (Web App) onde você deseja implantar seu aplicativo ASP.NET Core. Como essa etapa não é o foco deste tutorial, deixarei alguns artigos de referência para ajudar nesse processo. Entretanto precisamos baixar o Perfil de Publicação para continuar a configuração no GitHub.

Para esta etapa, na página do Serviço de Aplicativo criado, no menu superior, clique em “Baixar Perfil de Publicação”. O perfil de publicação será baixado como um arquivo XML. Salve esse arquivo em um local seguro no seu computador.

Etapa 3: Configure o Perfil de Publicação no Github Secrets

Volte para o GitHub e acesse o seu repositório. Vá para as "Settings" (Configurações) do repositório e clique em "Secrets and variables" e depois em “Actions”. Adicione um novo segredo chamado AZURE_PUBLISH_PROFILE e, como valor, insira o conteúdo do arquivo XML que você baixou (o conteúdo do perfil de publicação).

IMPORTANTE: Nunca compartilhe ou exponha o Perfil de Publicação do Azure publicamente. Ele contém informações sensíveis de autenticação e autorização que podem comprometer a segurança do seu aplicativo e dos seus recursos no Azure. Mantenha-o em um local seguro e restrito, acessível apenas para aqueles que realmente precisam dele para fins de implantação.

Etapa 4: Realizando o Deploy

Agora, com seu pipeline de CI/CD configurado, você pode monitorar seu funcionamento e fazer ajustes conforme necessário. O GitHub Actions se encarregará de construir, testar e implantar seu aplicativo no Azure sempre que houver um push na branch main.

Na barra de navegação superior do repositório, você verá a guia "Actions". Clique nela para acessar a página de ações. Você verá uma lista de todos os workflows (fluxos de trabalho) configurados para esse repositório. Os workflows são organizados por nome e exibem o status atual de execução. Você verá informações como o nome do workflow, a data da execução mais recente e o status (por exemplo, sucesso, falha, em execução).

Para obter mais informações sobre uma execução específica, clique no número da execução na lista. Isso o levará a uma página com detalhes completos sobre a execução, incluindo logs de cada etapa executada. Dentro dos detalhes da execução, você pode acessar os logs de cada etapa individual do workflow. Isso permite que você veja informações detalhadas sobre o que aconteceu em cada etapa da execução.

No Azure, na página do Serviço de Aplicativo, é possível verificar o log de implantações. Para isso, acesse o menu "Centro de Implantação" e, em seguida, clique em "Logs".

Conclusão

Configurar um pipeline de CI/CD para um aplicativo ASP.NET Core com o GitHub Actions é uma maneira eficaz de automatizar o processo de construção, teste e implantação. Isso permite que você entregue atualizações mais rapidamente e com mais confiança. Com as configurações e ajustes corretos, você pode criar um fluxo de trabalho robusto que melhora a qualidade e a eficiência do seu desenvolvimento de software.

Lembre-se de que as configurações e os ambientes de implantação podem variar de acordo com suas necessidades específicas, mas este guia serve como um ponto de partida para configurar seu próprio pipeline de CI/CD com o GitHub Actions.

Referências

Tratamento de Exceção Global no Asp.Net Core

Rodrigo Schemes — Tue, 05 Sep 2023 01:14:17 +0000

Introdução

O tratamento de exceção é uma parte importante do desenvolvimento de software. Quando algo dá errado em uma aplicação, é importante ter um mecanismo para lidar com a exceção e fornecer um feedback adequado para o usuário. No Asp.Net Core, podemos usar o Middleware UseExceptionHandler para lidar com exceções globalmente em toda a aplicação. Neste post, vamos apresentar um tutorial detalhado sobre como implementar um controle de erros de forma simples em sua API.

Implementar um tratamento de erro global em uma API pode trazer uma série de benefícios significativos para o desenvolvimento e manutenção do seu aplicativo. Aqui estão alguns dos principais benefícios:

Padronização do tratamento de erro: ajuda a garantir que a abordagem de tratamento de erro seja igual em todos os endpoints e evita duplicação de código.
Resposta amigável ao usuário: Você pode retornar respostas amigáveis e compreensíveis aos usuários quando ocorrerem erros. Evite mensagens técnicas!
Segurança: Tratar erros de forma adequada ajuda a evitar a exposição de informações sensíveis ou detalhes técnicos aos usuários ou a pessoas mal-intencionadas.
Monitoramento e análise: Permite que você tenha uma visão geral dos tipos de erros que estão acontecendo com mais frequência.
Tratamento de exceções não previstas: Um tratamento de erro global permite capturar exceções não previstas.

Criando o Middleware

Para criar o Middleware de tratamento de exceção, crie uma nova classe e nomeie-a como TratamentoErroGlobal.cs. Em seguida, adicione o seguinte código:

public static class TratamentoErroGlobal{

    public static void AdicionarTratamentoErroGlobal(this IApplicationBuilder app)
    {
        app.UseExceptionHandler(applicationBuilder =>
        {
            applicationBuilder.Run(async contexto =>
            {
                contexto.Response.StatusCode = (int)HttpStatusCode.InternalServerError;

                var erroNoRequest = contexto.Features.Get<IExceptionHandlerFeature>();

                if (erroNoRequest != null)
                {
                    var detalheProblema = new ProblemDetails
                    {
                        Status = (int)HttpStatusCode.InternalServerError,
                        Type = "Erro",
                        Title = "Erro no servidor",
                        Detail = "Ocorreu um erro interno."
                    };

                    await contexto.Response.WriteAsJsonAsync(detalheProblema);
                }
            });
        });
    }
}

Aqui está uma explicação sobre como essa classe funciona:

public static void AdicionarTratamentoErroGlobal(this IApplicationBuilder app)
- Isso define um método de extensão para a interface IApplicationBuilder que adiciona o Middleware de tratamento de erro global.
app.UseExceptionHandler(applicationBuilder => { ... })
- Aqui, o método UseExceptionHandler é chamado no IApplicationBuilder, configurando o Middleware de tratamento de exceção. O código dentro do bloco é uma função de Callback que lida com a exceção e cria uma resposta apropriada.
contexto.Response.StatusCode = (int)HttpStatusCode.InternalServerError
- Define o status code da resposta HTTP para 500 (InternalServerError) para indicar um erro no servidor.
var erroNoRequest = contexto.Features.Get<IExceptionHandlerFeature>()
- Obtém as informações sobre a exceção que ocorreu durante o processamento da requisição.
var detalheProblema = new ProblemDetails{ ... }
- Aqui, criamos um objeto ProblemDetails, que é uma classe padrão do ASP.NET Core usada para representar detalhes de um problema. Definimos o status, o tipo, o título e os detalhes do erro.
await contexto.Response.WriteAsJsonAsync(detalheProblema)
- Escreve a resposta como JSON contendo os detalhes do problema (representados pelo objeto ProblemDetails), utilizando o método assíncrono WriteAsJsonAsync.

Configurando a Injeção de Dependência do Middleware

Para configurar o Middleware de tratamento de exceção, precisamos adicionar o seguinte código em nossa classe Program.cs:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();

var app = builder.Build();
app.AdicionarTratamentoErroGlobal();
app.MapControllers();

app.Run();

O método AdicionarTratamentoErroGlobalé um método de extensão da classe TratamentoErroGlobal. Isso significa que ele estende a funcionalidade da interface IApplicationBuilder, permitindo adicionar um novo Middleware de tratamento de erros global à pipeline de processamento de solicitações do ASP.NET Core. Quando chamado no contexto da configuração da aplicação, ele configura o tratamento de erros global de forma apropriada.

Testando o Tratamento de Exceção Global

Para testar o tratamento de exceção global, podemos adicionar um código que gera uma exceção não tratada em uma de nossas Controllers. Quando executarmos a aplicação e acessarmos essa rota, o Middleware de tratamento de exceção retornará uma resposta em JSON para o usuário com os tratamentos que criamos anteriormente.

Crie uma classe chamada ExemploController.cs e adicione o seguinte código:

[ApiController]
[Route("api/exemplo")]
public class ExemploController : ControllerBase
{
    [HttpGet]
    public Task<IActionResult> ObterExemplo()
    {
        throw new Exception("Exceção causada intencionalmente");        
    }
}

Podemos compilar e iniciar a API e, em seguida, através do Postman, fazer uma chamada GET para a rota http://localhost:[Porta]/api/exemplo. O retorno esperado deve ser o seguinte:

{
    "type": "Erro",
    "title": "Erro no servidor",
    "status": 500,
    "detail": "Ocorreu um erro interno."
}

Conclusão

O tratamento de exceção é uma parte importante do desenvolvimento de software. No Asp.Net Core, podemos usar o Middleware UseExceptionHandler para lidar com exceções globalmente em toda a aplicação. Neste post, vimos como configurar o Middleware de tratamento de exceção e devolver uma resposta personalizada para o usuário.

Esta abordagem apresenta os seguintes benefícios:

Simplicidade: UseExceptionHandler é simples de configurar. Você pode simplesmente fornecer um Middleware para tratamento de erros e o ASP.NET Core cuida do resto.
Recursos integrados: fornece suporte integrado para exibir páginas de erro amigáveis ao desenvolvedor ou retornar respostas de erro no formato JSON, dependendo do tipo de solicitação.
Consistência: por ser um recurso padrão do ASP.NET Core, ele garante uma abordagem consistente de tratamento de erros em diferentes partes do seu aplicativo.
Configuração centralizada: você pode configurar facilmente o tratamento de erros em um só lugar, facilitando o gerenciamento e a atualização.

Como contras desta abordagem, destaco o seguinte:

Customização limitada: embora forneça algumas opções de personalização, UseExceptionHandler pode não cobrir todos os cenários específicos de tratamento de erros que seu aplicativo exige.
Controle de log limitado: você pode ter controle limitado sobre como os erros são logados. O comportamento de log personalizado pode exigir soluções alternativas adicionais.

Em resumo, se as necessidades de tratamento de erros do seu aplicativo puderem ser atendidas pelos recursos fornecidos pelo UseExceptionHandlerMiddleware, é uma abordagem conveniente e direta. Por outro lado, se você precisar de mais controle, personalização e flexibilidade, construir um Middleware customizado implementando a interface IMiddlewarepode ser a melhor escolha (e tema para um próximo post). Tenha em mente a complexidade da sua aplicação, a familiaridade da sua equipe com a tecnologia e as considerações de manutenção a longo prazo ao tomar esta decisão.

DEV Community: Rodrigo Schemes

🎮 Singleton e Concorrência em C# — Um Joguinho pra Aprender de Verdade

🔄 O que é Singleton, afinal?

Por que usar isso?

🕹️ O jogo: como funciona?

⚙️ Como fiz funcionar direitinho (sem bugs de concorrência)

1. lock para proteger a pontuação

2. Um cuidado com o Random

3. Execução concorrente com Task.Run

4. Ranking final com ConcurrentDictionary

🏁 Resultado típico

💭 O que eu aprendi com isso

🔗 Código-fonte no GitHub

Decorator Pattern com Scrutor no Asp.Net Core

Introdução

Decorator Pattern

Scrutor

Implementando o Decorator Pattern com Scrutor

Testando a implementação

Conclusão

Referências

CI/CD ASP.NET Core com GitHub Actions e Azure

Introdução

O que é o GitHub Actions?

Pré-requisitos

Configurando o Pipeline

Etapa 1: Adicione um arquivo de configuração para o GitHub Actions

Etapa 2: Configure o ambiente de implantação no Azure

Etapa 3: Configure o Perfil de Publicação no Github Secrets

Etapa 4: Realizando o Deploy

Conclusão

Referências

Tratamento de Exceção Global no Asp.Net Core

Introdução

Criando o Middleware

Configurando a Injeção de Dependência do Middleware

Testando o Tratamento de Exceção Global

Conclusão

Referências

1. `lock` para proteger a pontuação

2. Um cuidado com o `Random`

3. Execução concorrente com `Task.Run`

4. Ranking final com `ConcurrentDictionary`