DEV Community: Diogo Kobbi

C# - Delegates (Parte 1)

Diogo Kobbi — Tue, 18 Aug 2020 12:22:40 +0000

De modo simplificado, podemos considerar delegates como objetos que sabem invocar métodos - ou métodos que são tratados como objetos, como preferir. É um tipo que representa uma referência a métodos com determinado tipo de retorno e parâmetros.

Quando criamos uma instância de um delegate podemos associá-lo a qualquer método com assinatura compatível (retorno e parâmetros) e executá-lo mais tarde em nosso código.

Como criar e executar um delegate

A declaração de um tipo delegate é similar a assinatura de um método. Ela tem um tipo de retorno e um ou mais parâmetros de diversos tipos:

delegate Identificador ([parâmetros])
Após a criação, basta executar* o método usando o nome do objeto ou o método invoke:

delegate double CalculoMatematico(float valor1, float valor2);

public static class Calculadora {

   public static double Somar(float valor1, float valor2) => valor1 + valor2;

}

CalculoMatematico soma = Calculadora.Somar;

var resultado1 = soma.Invoke(2, 3);

var resultado2 = soma(3, 4);

*Importante: em um projeto real é melhor verificar se o objeto é nulo antes de invocá-lo.

Action e Func

Embora exista a possibilidade, nem sempre precisamos criar nossos próprios delegates. Também podemos utilizar os delegates Action e Func para agilizar nosso desenvolvimento.

Em vez de especificarmos a assinatura do delegate para depois utilizá-lo como tipo:

delegate doubleCalculoMatematico(float valor1, float valor2);

CalculoMatematico soma = Calculadora.Somar;

Podemos especificar na própria atribuição da variável:

Func<float, float, double> soma = Calculadora.Somar;

A diferença entre Action e Func é que um Action não retornará um valor, enquanto Func retornará um valor do tipo definido na declaração - ao declarar um Func, o último argumento sempre indicará o tipo de retorno (no exemplo acima, double será o tipo do retorno).

Qual forma é melhor? Depende. Criar delegates nos permite controlar melhor o nosso código, pois o nome que damos ao delegate nos ajuda a entender sua função. As duas formas tem seus prós e contras.

Para que serve um delegate?

Um uso muito comum é utilizar delegates em métodos de callback - um método de callback é um pedaço de código executável que é passado como parâmetro para algum método, é esperado que o método execute o código do argumento em algum momento. Veja, por exemplo, a declaração do método Where da Classe Enumerable:

Where<TSource>(IEnumerable<TSource>, Func<TSource,Boolean>)  
//Filtra uma sequência de valores baseado em um predicado

Este método recebe um delegate (Func) como parâmetro que retornará um valor do tipo falso ou verdadeiro, o que significa que podemos utilizá-lo da seguinte maneira:

bool SaldoNegativo(float saldo) {

  return saldo < 0;

}

var contas = new List<ContaCorrente>();
contas.Add(...);
var clientesUsandoChequeEspecial = contas.Where(SaldoNegativo);

Ou criando uma função anônima (assunto para outro artigo) que tenha a mesma assinatura:

var clientesUsandoChequeEspecial = contas.Where(x => x.Saldo < 0);

Veja que atribuir um método a uma variável e utilizá-la em outros trechos do código nos ajuda a manter o nosso código fortemente tipado, pois forçamos o uso da mesma assinatura e evitamos que um método totalmente fora do propósito seja executado. Afinal, se não obrigássemos que uma função específica fosse utilizada, outros desenvolvedores poderiam passar delegates incompatíveis e o filtro do método where não funcionaria corretamente, não é mesmo?

No próximo artigo falarei sobre outros temas como Covariância, Multicast e Eventos, outro uso comum de delegates.

Até mais!

ASP.Net Core 3.0 - Conhecendo a plataforma

Diogo Kobbi — Wed, 12 Aug 2020 13:33:14 +0000

ASP.NET Core é um framework projetado para criação de aplicações conectadas a internet. Ele tem uma estrutura modular e pode ser dividido em uma plataforma para processar requisições HTTP, uma série de frameworks para criar diferentes tipos de aplicações, e frameworks auxiliares para enriquecer a aplicação com mais funcionalidades:

Fonte: Pro ASP.NET Core 3, Develop Cloud-Ready Web Applications Using MVC, Blazor, and Razor Pages - Adam Freeman

No ASP.Net Core os frameworks utilizados na criação das aplicações estão "separados" do resto da plataforma. Isso significa que, mesmo sendo o padrão mais utilizado, as aplicações ASP.Net Core não são obrigadas a utilizar o MVC. Podemos utilizar Razor Pages para criar websites, Blazor para criar SPA's e até mesmo desenvolver para IoT!

Como uma aplicação ASP.Net Core funciona

A plataforma possui diversos componentes, mas existem recursos chave que nos ajudam a entender melhor o mecanismo interno do ASP.Net Core:

middlewares
pipeline da requisição
services.

Nas aplicações conectadas as internet, uma resposta precisa ser gerada para atender uma requisição, e são estes componentes que farão boa parte do trabalho.
Middlewares

Quando uma requisição chega a aplicação, o ASP.Net Core cria um objeto que representa a requisição (context.request) e um objeto que representará sua resposta (context.response). Estes objetos são então passados a pedaços de software chamados middlewares para que sejam processados a fim de gerar a resposta desejada ao cliente.

Middlewares podem ser funções anônimas ou classes. O ASP.Net Core possui diversos middlewares nativos que nos ajudam a resolver problemas comuns no desenvolvimento de aplicações conectadas a internet, mas também podemos criar novos middlewares a fim de atendermos requisitos específicos da nossa aplicação. O mais importante para nós neste momento é entender o papel que eles possuem na plataforma. Eles realizam sua tarefa com a requisição e em seguida:

encaminham a requisição para o próximo middleware na "cadeia de processamento";
interrompem a cadeia antecipadamente (em caso de erros, por exemplo);

Importante: se a resposta não for gerada por nenhum middleware, o ASP.Net Core retornará por padrão uma resposta HTTP 404 para o cliente.

O pipeline da requisição

Falamos em "cadeia de processamento" no tópico anterior pois no ASP.Net Core os middlewares são organizados em cadeia, e ficam responsáveis por "chamar" o próximo middleware para execução. Este conjunto de middlewares recebe o nome de request pipeline:

Com o ASP.Net Core temos total controle na criação deste pipeline, mas devemos estar atentos a ordem em que eles são configurados. O middleware que convoca fica aguardando a resposta do middleware que foi convocado, portanto, o primeiro middleware a receber a requisição será o último a receber a resposta. Essa sequência afeta o funcionamento da aplicação e também pode impactuar sua segurança e performance.

Agora que conhecemos o request pipeline, como seria a aplicação mais simples possível criada com ASP.Net Core?
A aplicação mais simples é a que possui apenas um middleware para responder todas as requisições da aplicação. Veja um exemplo:

public class Startup {   

    public void Configure(IApplicationBuilder app)    {       
        app.Run(async context => {           
            await context.Response.WriteAsync("Hello, World!");       
        });   
    }
}

Neste aplicação, todos os clientes receberão o texto "Hello, World!" no corpo da resposta HTTP.
Services

Nem todos os componentes da aplicação precisam fazer parte do pipeline. Também precisamos de objetos que realizem cálculos, acessem bancos de dados, processem arquivos em disco, entre outras funcionalidades. Serviços no ASP.Net Core são estas dependências que utilizamos em nossa aplicação.

Objetos interagem com outros objetos para cumprir determinada tarefas, e para dizer ao ASP.Net Core quais objetos desejamos utilizar, precisamos configurá-los como serviços em nossa aplicação. Por esta razão eles são um conceito chave nas aplicações ASP.Net Core. São eles que realizam uma parte fundamental do trabalho para que a resposta gerada corretamente para o cliente.

A utilização de serviços trazem diversos benefícios. Ela evita a repetição de código, ajuda a manter o baixo acoplamento e nos permite seguir o princípio de Inversão do Controle (SOLID). Separamos estes códigos em serviços para que possam ser reutilizados dentro da aplicação ou até mesmo em outras aplicações.

Juntando as peças

Juntando todos as peças podemos visualizar melhor como o ASP.Net Core trabalha para atender todas as requisições dos clientes. Toda requisição recebida pela aplicação é encaminhada ao pipeline, onde cada middleware com a ajuda ou não de um ou mais services, processa e convoca o próximo middleware na cadeia de processamento, até que a cadeia de processamento termine e gere a resposta final para o cliente:

Fonte: Pro ASP.NET Core 3, Develop Cloud-Ready Web Applications Using MVC, Blazor, and Razor Pages - Adam Freeman

Curtiu? Siga o meu perfil para mais conteúdo sobre desenvolvimento .Net e C#. Bons estudos!

Referências: