DEV Community: Roberto Higor

Injeção de dependência e inversão de controle

Roberto Higor — Sun, 26 Mar 2023 23:40:32 +0000

Dependência

Uma dependência é quando uma classe depende de outra para realizar uma função, de forma a utilizar um recurso. Digamos que em uma aplicação que possui um componente de edição de textos, você quer adicionar a funcionalidade de verificação ortográfica, por exemplo:

No diagrama acima, o SpellChecker é uma dependência de TextEditor. A classe TextEditor está dependendo diretamente de SpellCHecker, tendo a responsabilidade de instânciar e chamar a outra classe.

Isso permite a reutilização dessa funcionalidade por outras classes, porém gera um acoplamento forte entre as classes, sendo representado no código abaixo:

public class TextEditor {
    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

Inversão de controle

Inversão de controle é uma técnica em que o controle é invertido na hierarquia de dependência entre as classes. Isso significa que uma classe dependente recebe suas dependências de uam classe externa, ao invés de cria-las internamente.

Orientação a interfaces

No primeiro exemplo, é gerado diversos problemas devido ao acoplamento a uma classe concreta, como:

Para substituir a classe SpellChecker com uma implementação diferente, é preciso alterar a classe TextEditor;
Caso SpellChecker tenha outras dependências, elas precisam ser configuradas pela classe TextEditor. Isso resulta em um código de configuração espalhado caso várias classes do sistema utilizem o SpellChecker;
Não é possível criar mocks para testes unitários, por depender da implementação de SpellChecker.

Para resolver parte do acoplamento, o primeiro passo para reduzir o acoplamento é através do design orientado a interfaces. Com uma classe orientada a interfaces, é possível a alteração de uma implementação sem que afeta a classe que utilize essa dependência.

Um segundo passo é transferir a responsabilidade de criar os objetos das dependências para quem utiliza a classe, tendo ela então a responsabilidade de injetar a dependência, não mais o TextEditor.

O diagrama acima mostra a utilização do TextEditor por uma outra classe (como a classe Main), tendo o controle sobre qual implentação da interface ISpellChecker utilizar, fornecendo-a antes de utilizar em si a TextEditor.

Adaptando o exemplo acima, a classe TextEditor deve depender da interface de SpellChecker, e não mais da implementação. Além disso, ela deve dar a responsabilidade de injetar a implementação para outra classe, nesse exemplo é utilizado a injeção via construtor:

public class TextEditor {
    private ISpellCHecker checker;

    public TextEditor(ISpellCHecker checker) {
        this.checker = checker;
    }
}

Já o código para utilização da classe (caso não utilizar um framework para ajudar):

ISpellChecker sc = new SpellChecker(); // Implementação de ISpellChecker
TextEditor textEditor = new TextEditor(sc);
bool textoOk = textEditor.Check();

Injeção de dependências

Conforme um sistema vai crescendo, a criação de vários objetos pode se tornar um processo complexo e trabalhoso. Uma maneira é tornar necessário apenas com que o componente solicite a dependência, e não mais o fornecimento por um componente. Isso é possível através da injeção de dependência.

A injeção de dependência (ou dependency injection) é uma design pattern para sistemas com orientação a objetos, sendo uma especialização de inversão de controle tendo (IoC) o objetivo de injetar dinamicamente dependências em uma classe, em tempo de execução. Nesse caso, a responsabilidade de construir os objetos para um framework.

Tipos de injeção de dependência

Mesmo utilizando um framework para o fornecimento de dependências, é necessário com que a classe tenha uma maneira de receber essa implementação. O método utilizado servirá tanto com o uso do framework, quanto para uma injeção manual, sendo as 2 principais maneiras:

Injeção via construtor

É o exemplo utilizado acima, onde para construir uma instância de TextEditor, é obrigado fornecer uma implementação de ISpellChecker
Injeção via Setter

Para esse caso, após instanciar a classe, a injeção é realizada via um método set, por exemplo:

public class TextEditor {
    private ISpellChecker checker;

    public TextEditor() {
    }

    public SetSpellChecker(ISpellChecker checker) {
        this.checker = checker
    }
}

Service Container do ASP.NET Core

O ASP.NET Core possui um container de serviços, onde é possível registrar as dependências. O .NET ficará responsável por criar e eliminar instâncias da dependência onde for necessário. É a partir dele que iremos aplicar a injeção de dependência.

ele torna mais fácil a configuração de implementações, ao invés de levar a responsabilidade de fornecer manualmente a implementação para uma classe, antes de conseguir utiliza-la, o que pode ser um processo demorado.

No container de serviços, é qual implementação de cada interface utilizar. Dessa forma, quando uma nova instância é requisitada, ele automaticamente resolve as dependências.

Ciclo de vida de uma dependência

Uma das principais vantagens da utilização de um container de IoC é o controle do ciclo de vida da instância da dependência, sem com que o desenvolvedor se preocupe em desenvolver essa lógica.

A escolha do ciclo de vida é realizada na etapa do registro da implementação, sendo os ciclos disponíveis no C#:

Singleton - Uma instância compartilhada por todas as requisições;
Scoped - Uma instância por requisição;
Transient - Uma instância por chamada, sendo sempre diferentes.

Transferindo para código, cada forma ficaria da seguinte maneira:

services.AddSingleton<IMyDependency, Myependency>() // Singleton
services.AddScoped<IMyDependency, Myependency>() // Scoped
services.AddTransient<IMyDependency, Myependency>() // Transient

Existem casos específicos de quando usar cada uma das implementações. Por exemplo, Singleton pode ser ideal para classes de cache, por ser acessadas em todas as requisições. Essas diferenças e seus casos de uso serão discutidos no próximo artigo.

Conclusão

A inversão de controle é uma forma com que conseguimos injetar as dependências de uma classe através de uma classe externa, que junto do design orientado a interfaces, Ajuda na redução de acoplamento entre as classes.

Já a injeção de dependência, é um tipo de IoC no qual registramos o ciclo de vida e implementação de uma interface, transferindo a responsabilidade de criação de objetos para um framework, e eliminando a necessidade de criar manualmente cada objetos, o que pode se tornar complexo em sistemas grandes.

Caso tenha alguma informação incorreta, ou algum ponto a acrescentar, não deixe de comentar.

Fontes

https://stackoverflow.com/questions/3058/what-is-inversion-of-control

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-7.0

https://stackoverflow.com/tags/dependency-injection/info

https://stackoverflow.com/questions/130794/what-is-dependency-injection

https://stackoverflow.com/questions/4596300/where-exactly-is-the-difference-between-ioc-and-di

https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff921087(v=pandp.10)

https://imasters.com.br/software/inversao-de-controle-service-locator-e-injecao-de-dependencia

Porque você precisa conhecer o StringBuilder

Roberto Higor — Thu, 09 Mar 2023 00:21:06 +0000

Introdução

Nesse artigo vou explicar as vantagens e diferenças entre a classe StringBuilder e a concatenação de strings com "+". Por ser uma ferramenta muito utilizada no dia a dia, é importante entender as diferenças de como as duas funcionam internamente.

Mutável vs Imutável

A classe String é do tipo imutável, ou seja, após criado seu valor não pode ser alterado. Apesar de parecer que ao adicionar uma string a outra existente, estamos apenas incrementando a variável anterior com mais valores, na realidade é alocado e criado uma nova variável na memória contendo a junção das duas strings, por exemplo:

string textoOriginal = "Olá, ";
string mundo = "Mundo";
// Internamente está sendo criado uma nova string e 
// alocado na variável já existente.
textoOriginal += mundo;

Internamente, o compilador converte a operação "+" em String.Concat

Para processos onde é realizado manipulações em string em um alto volume, isso pode resultar em um impacto tanto na performance quanto no uso de memória, por ser necessário uma nova alocação a cada concatenação, resultando também em chamadas excessivas ao Garbage Collector.

Para casos onde precisamos de uma variável mutável, a alternativa é a classe StringBuilder que, diferente da String, trabalha com dados mutáveis. Ou seja, uma instância do StringBuilder pode ser modificada (incrementadas, substituidas etc) sem precisar criar uma nova instância. Essa é sua principal vantagem, que é feito através do uso de um buffer interno, no qual permite com que o valor da string aumente e diminua.

Buffer

Diferente da String, o StringBuilder trabalha com um buffer para acomodar as modificações. Caso o buffer se esgote, será alocado um buffer maior, copiando os dados do buffer antigo. A alocação padrão do StringBuilder comporta 16 caracteres, tendo o máximo o valor da constante Int32.MaxValue, que ao atigindo, resulta em um OutOfMemoryException.

Para reduzir a frequência no qual é alocado mais memória para o buffer interno, pode-se utilizar o construtor que recebe o tamanho da memória no qual queremos alocar (em caracteres)

// Inicia stringbuilder com tamanho para 100 caracteres
var sb = new StringBuilder(100)

É dito que uma alocação exata pode trazer uma melhorias na performance e redução na alocação de memória, no entanto nos exemplos realizados a versão com Buffer após um certo volume de dados trouxe performance pior do que a versão sem buffer.

  [Benchmark]
    public string StringBuilderLoop1kComBufferTest()
    {
        StringBuilder stringBuilder = new("Olá, ", 1000 * "Mundo".Length);
        for (int i = 0; i < 1000; i++)
            stringBuilder.Append("Mundo");
        return stringBuilder.ToString();
    }

    [Benchmark]
    public string StringBuilderLoop1kSemBufferTest()
    {
        StringBuilder stringBuilder = new("Olá, ");
        for (int i = 0; i < 1000; i++)
            stringBuilder.Append("Mundo");
        return stringBuilder.ToString();
    }

        [Benchmark]
    public string StringBuilderLoop10kComBufferTest()
    {
        StringBuilder stringBuilder = new("Olá, ", 10000 * "Mundo".Length);
        for (int i = 0; i < 10000; i++)
            stringBuilder.Append("Mundo");
        return stringBuilder.ToString();
    }

    [Benchmark]
    public string StringBuilderLoop10kSemBufferTest()
    {
        StringBuilder stringBuilder = new("Olá, ");
        for (int i = 0; i < 10000; i++)
            stringBuilder.Append("Mundo");
        return stringBuilder.ToString();
    }

Method	Mean	Error	StdDev	Gen0	Gen1	Gen2	Allocated
StringBuilderLoop1kComBufferTest	3.846 us	0.0176 us	0.0156 us	1.8005	0.1144	-	29.47 KB
StringBuilderLoop1kSemBufferTest	4.383 us	0.0256 us	0.0214 us	1.6174	0.0916	-	26.5 KB
StringBuilderLoop10kComBufferTest	94.036 us	0.4714 us	0.4410 us	62.3779	62.3779	62.3779	211.13 KB
StringBuilderLoop10kSemBufferTest	70.643 us	0.9460 us	0.8386 us	31.1279	31.1279	31.1279	208.57 KB

Para a execução do método Append() mil vezes, a versão com buffer teve uma performance um pouco melhor. No entanto, para a versão de 10 mil vezes, a performance foi consideravelmente pior.

AppendJoin vs Join

Ambas as classes possuem também métodos de Join, sendo StringBuilder.AppendJoin e String.Join. Para casos onde temos um array de strings, o string.Concat pode ser uma alternativa melhor por conseguir determinar o tamanho final da string ao examinar o array.

Em casos onde é necessário chamar várias vezes (como em um loop), o AppendJoin consegue se sair melhor pela vantagem da imutabilidade.

O StringBuilder.AppendJoin é uma combinação entre o String.Join e o StringBuilder.Append, por chamar o Append internamente. Para cada valor, também é chamado o ToString(), o que pode ser ruim para valores que não são string (como int e decimal).

A comparação pode ser vista no benchmark abaixo:

private static string[] _dataList = 
    System.IO.File.ReadAllLines(@"randomString200-1.txt");

    [Benchmark]
    public string StringBuilderJoin()
    {
        StringBuilder stringBuilder = new();
        stringBuilder.AppendJoin("", _dataList);
        return stringBuilder.ToString();
    }

    [Benchmark]
    public string StringJoin()
    {
        return String.Join("", _dataList);
    }

     [Benchmark]
    public string StringConcat()
    {
        return String.Concat(_dataList);
    }

Method	Mean	Error	StdDev	Gen0	Gen1	Allocated
StringBuilderJoin	4.041 us	0.0410 us	0.0383 us	5.1193	0.8469	83.71 KB
StringJoin	2.363 us	0.0460 us	0.0644 us	2.0523	-	33.69 KB
StringConcat	1.686 us	0.0127 us	0.0119 us	2.0523	-	33.69 KB

Nesse caso o String.Concat teve uma performance melhor (pelo fato do exemplo utilizar um array), além de alocar menos memoria do que o StringBuilder.Join. Em seguida vem o StringJoin.

Para os cenários de Array com tamanho fixo, o próprio String.Concat consegue se sair melhor.

Quando utilizar

O StringBuilder é recomendado quando se utiliza um alto volume de concatenações de string, como por exemplo em um loop. Segundo a microsoft, a classe String deve ser utilizada em casos de:

Quando o número de modificações na string for pequeno;
Quando é realizado um número fixo de concatenações, pois nesse caso o compilador pode combinar em uma única operação;
Quando é necessário utilizar métodos de pesquisas como IndesOf ou StartsWith, pelo fato do StringBuilder não suportar sem antes o converter em String, o que negaria seus benefícios.

Já para o caso de uso do StringBuilder:

Quando o código pode fazer um número desconhecido de modificações (como em loops);
Quando o código fará um número significativo de alterações em uma string.

Ao realizar a concatenação de uma palavra 100 mil vezes, a vantagem do StringBuilder fica bem evidente:

   [Benchmark]
    public string StringBuilderLoopTest()
    {
        StringBuilder stringBuilder = new("Olá, ");
        for (int i = 0; i < 100000; i++)
            stringBuilder.Append("Mundo");
        return stringBuilder.ToString();
    }

    [Benchmark]
    public string StringConcatLoopTest()
    {
        string textoOriginal = "Olá, ";
        string mundo = "Mundo";
        for (int i = 0; i < 100000; i++)
            textoOriginal += mundo;
        return textoOriginal;
    }

Method	Mean	Error	StdDev	Gen0	Gen1	Gen2	Allocated
StringBuilderTest	18.642 ns	0.3487 ns	0.3261 ns	0.0091	-	-	152 B
StringConcatTest	8.216 ns	0.0610 ns	0.0571 ns	0.0029	-	-	48 B
StringBuilderLoopTest	699,651.201 ns	2,971.4637 ns	2,779.5089 ns	249.0234	249.0234	249.0234	2013684 B
StringConcatLoopTest	5,013,108,142.857 ns	24,203,777.6872 ns	21,456,018.4848 ns	11800000.0000	11779000.0000	11776000.0000	50007779072 B

Além do menor tempo de execução e memória alocada, com o StringBuilder houve menos chamadas ao Garbage Collector Gen 0, devido ao fato da concatenação alocar mais memória ao criar novos objetos de string, resultando em mais chamadas ao GC Generation 0.

Quando não utilizar

Para strings pequenas, o StringBuilder pode não trazer um ganho muito significativo de memória, além de que utilizar o "+=" nesses casos possuí uma sintaxe mais simples e rápida de se desenvolver.

Outro caso é quando já existe um array de strings de tamanho definido, como citado no capítulo sobre Join, em que o String.Concat consegue determinar de uma vez o quanto é preciso alocado.

Exemplo de quando não utilizar:

using System.Text;
using BenchmarkDotNet.Attributes;

namespace Domain.Benchmark;
[MemoryDiagnoser]
public class StringBuilderBenchmark
{
    [Benchmark]
    public string StringBuilderTest()
    {
        `StringBuilder` stringBuilder = new("Olá, ");
        stringBuilder.Append("Mundo");
        return stringBuilder.ToString();
    }

    [Benchmark]
    public string StringConcatTest()
    {
        string textoOriginal = "Olá, ";
        string mundo = "Mundo";
        return textoOriginal + mundo;
    }
}

Nesse caso, o StringBuilder além de ter sido mais lento, alocou mais memória do que a concatenação normal.

Method	Mean	Error	StdDev	Gen0	Allocated
StringBuilderTest	18.626 ns	0.1947 ns	0.1726 ns	0.0091	152 B
StringConcatTest	8.320 ns	0.0479 ns	0.0425 ns	0.0029	48 B

Conclusão

Esse artigo buscou mostrar de forma breve as vantagens e quando utilizar a classe StringBuilder, sendo uma grande aliada na performance de sistemas que executem um grande volume de concatenações de string. Seu uso deve ser mais para casos onde não sabemos o tamanho da string, pela sua propriedade de ser mutável. Em casos em que sabemos o tamanho, como ao juntar um array de strings, o string.Concat consegue uma vantagem.

Seguem os resultados dos benchmarks com tamanhos de string variados:

Method	Mean	Error	StdDev	Rank	Gen0	Gen1	Gen2	Allocated
StringBuilderTest	19.107 ns	0.2487 ns	0.2205 ns	2	0.0091	-	-	152 B
StringConcatTest	8.414 ns	0.1637 ns	0.1531 ns	1	0.0029	-	-	48 B
StringBuilderLoop1kTest	4,503.729 ns	85.7993 ns	80.2567 ns	3	1.6174	0.0916	-	27136 B
StringConcatLoop1kTest	161,308.281 ns	3,194.8901 ns	4,154.2595 ns	5	301.2695	7.5684	-	5040000 B
StringBuilderLoop10kTest	70,641.925 ns	698.0930 ns	652.9966 ns	4	31.1279	31.1279	31.1279	213579 B
StringConcatLoop10kTest	20,383,109.233 ns	400,692.3340 ns	492,086.1706 ns	7	64593.7500	46625.0000	43625.0000	500414677 B
StringBuilderLoop100kTest	709,105.225 ns	7,222.7404 ns	6,402.7713 ns	6	249.0234	249.0234	249.0234	2013684 B
StringConcatLoop100kTest	5,111,168,506.667 ns	76,749,055.3313 ns	71,791,113.9755 ns	8	11783000.0000	11762000.0000	11759000.0000	50007763560 B

Fonte

https://www.stevejgordon.co.uk/creating-strings-with-no-allocation-overhead-using-string-create-csharp
https://learn.microsoft.com/pt-br/dotnet/api/system.text.stringbuilder?view=net-7.0#the-string-and-stringbuilder-types
https://medium.com/c-sharp-progarmming/stringbuilder-vs-concatenation-in-net-b817ccec331e
https://www.macoratti.net/21/11/c_benchmark1.htm
https://www.oreilly.com/library/view/c-cookbook/0596003390/ch02s22.html
https://www.infoworld.com/article/3616600/when-to-use-string-vs-stringbuilder-in-net-core.html
https://davecallan.com/improve-performance-stringbuilder-dotnet-setting-capacity/
https://andrewlock.net/a-deep-dive-on-stringbuilder-part-2-appending-strings-built-in-types-and-lists/

Retornando dado específico em API REST ASP.NET Core

Roberto Higor — Sun, 21 Mar 2021 03:31:28 +0000

Existem algumas diferenças entre a rota de listagem de todos os dados e da listagem específica. Entre elas, as duas que se destacam são:

Precisamos receber um parâmetro indicando qual objeto retoranr
Precisamos verificar se o objeto existe ou não para que seja retornada uma mensagem de erro.

Uma rota para retornar um objeto do tipo Palavra, sendo especificado pelo seu id recebe a seguinte anotação:

[HttpGet]
[Route("{id}")]
public async Task Palavra GetPalavra(int id)
{
    ...
}

Estamos dizendo pro ASP.NET core que nossa rota irá receber um parâmetro, que estamos chamando de id. Isso pois, caso queiramos retornar a palavra com id 2, iremos realizar uma chamada na rota /api/Palavras/2.

No exemplo acima, dizemos então que a rota recebe um atributo chamado id. Esse atributo é passado como argumento do método de nossa rota, nesse caso int id. Através dessa variável, podemos realizar diversas ações específica a essa rota. No código abaixo, vemos um exemplo simples de retornar uma Palavra por id.

[HttpGet]
[Route("{id}")]
public async Task ActionResult<Palavra> GetPalavra(int id)
{
    try 
    {
        var palavra = await _repository.GetPalavraPorId(id);
        return palavra;
    }
    catch (Exception)
    {
        return this.StatusCode(StatusCodes.Status500InternalServerError, "Database failure");
    }

}

Retornando Not Found

O código acima possuí um problema. No caso de não haver uma palavra com o id recebido, é retornado o código HTTP 204: No Content

O correto seria retornar uma mensagem de erro para o cliente, com o retorno 404 Not Found. Sabemos que existe um método que retorna esse erro, o NotFoun(), basta então checarmos no controller se o retorno do banco está vazio ou não

[HttpGet]
[Route("{id}")]
public async Task ActionResult<Palavra> GetPalavra(int id)
{
    try 
    {
        var palavra = await _repository.GetPalavraPorId(id);
        if (palavra == null) return NotFound();
        return palavra;
    }
    catch (Exception)
    {
        return this.StatusCode(StatusCodes.Status500InternalServerError, "Database failure");
    }

}

Nosso código agora, irá retornar o erro 404 caso a Palavra não seja encontrada no banco de dados, junto de um JSON que segue a RFC 7807.

{
  "type": "https://tools.ietf.org/html/rfc7231#section-6.5.4",
  "title": "Not Found",
  "status": 404,
  "traceId": "|6b16da39-47c24449f9eb6854."
}

E, como antes, no caso do método ser executado com sucesso, é retornado nosso objeto em JSON com o código HTTP 200: OK.

Exceptions

Uma boa prática de quando acontecer uma exception é realizar um log dela e retornar um erro 500. Para isso, capturamos a exception e escrevemos no log. Isso pode ser feito tanto no catch quanto em um filtro que captura exceptions.

O cliente então irá receber um código 500 caso ocorra algum erro interno. Se formos lançar essa exception, a aplicação irá ser suspendida, o que não seria uma boa ideia. Exceptions podem ser erros como um banco de dados indisponível, onde não temos controler por ser algo inesperado.

Fontes

https://docs.microsoft.com/pt-br/aspnet/core/mvc/controllers/routing?view=aspnetcore-5.0#ar
http://www.macoratti.net/19/06/aspnc_3dwebapi1.htm
https://docs.microsoft.com/pt-br/aspnet/core/mvc/controllers/filters?view=aspnetcore-5.0#exception-filters

API Rest simples com Asp.Net Core

Roberto Higor — Mon, 08 Mar 2021 16:43:23 +0000

API Rest simples para retornar dados

1. Criando controller

Para o controller, é criado uma classe que herda de ControllerBase. Existe também a herança de Controller, porém ela é utilizada somente em projetos com manipulação de páginas da Web, não para solicitações de API WEB.

A classe recebe a anotação [ApiController], que fornece algumas funcionalidades como binding sources, validações com [Required], fazendo com que seja disparado o erro 400 Bad Request automáticamente no caso de erro de validação. Além disso, resultados de erro (código de status 400 ou superior) irão retornar uma resposta em JSON que segue a RFC 7807.

{
  type: "https://tools.ietf.org/html/rfc7231#section-6.5.4",
  title: "Not Found",
  status: 404,
  traceId: "0HLHLV31KRN83:00000001"
}

Em seguida, a classe recebe uma anotação [Route("api/[controller]"). O argumento [controller] faz com que a rota receba o nome da classe, tirendo o sufixo Controller. Por exemplo, uma classe chamada Palavras*Controller* terá, nesse caso, a rota api/Palavras.

2. Criando uma rota GET

As rotas seguem uma estrutura de pasta.

api/Palavras
    GetDefinicao

No caso de uma classe que está recebendo a rota api/Palavras. Caso seja criado um método, por exemplo, em uma rota customizada chamada GetDefinicao, a URI da rota será de api/Palavras/GetDefinicao.

O método da rota recebe uma anotação indicando sua operação HTTP (GET, POST, PUT, PATCH, DELETE ETC). No caso de uma rota para busca de recursos, utiliza-se [HttpGet].

Uma rota GET de recursos geralmente busca os recursos utilizando um repositório, guardando o resultado em uma variável. Em seguida, é retornado os valores para o cliente, que serão automaticamente mapeados para JSON.

Retornos

No ASP.NET Core existe métodos para retornar status code, como BadRequest() e NotFound(). Esses métodos estão disponíveis ao definir o tipo de retorno da rota como ActionResult ou IActionResult. Nesse caso, utilizaremos o método para retornar Ok junto do conteúdo, que é passado como argumento. É interessante sempre retornar esses status codes, ao invés de lançar uma exceção para que o cliente receba a resposta em JSON e a aplicação não pare.

Para retornar um objeto ou lista de objetos, é passado o tipo dentro de ActionResult. No caso de uma lista de objetos da classe Command, é retornado .

ActionResult<IEnumerable<Palavra>>
// ou
ActionResult<IList<Palavra>>

A diferença entre passar um tipo para ActionResult<T> ou utilizar IActionResult sem passar um tipo é a de que, no primeiro caso, será retornado automaticamente um Ok() se o tipo for o mesmo do específicado, pois o retorno é convertido para ObjectResult. Caso contrário, será retornado um status code de erro

IActionResult é útil quando o retorno pode ser de diversos tipos.

Para rotas que utilizam repositórios async, é passado a assinatura async com o retorno Task, como Task<IActionResult>, lembrando de passar a assinatura await no método assíncrono. Métodos async são úteis quando se espera uma operação externa, como por exemplo esperar o banco retornar os dados requisitados. Dessa maneira, a aplicação não é bloqueada enquanto aguarda esse retorno, podendo fazer outras requisições com outros clientes. E.g

var results = await _repository.GetAllPalavras(includeTalks);

Código completo

[HttpGet]        
public async Task<IActionResult> Get()
{
    try
    {
        // Por ser async, é necessario await
        // Caso contrário, será retornado o OK mesmo sem atribuir o results.
        var palavras = await _repository.GetAllPalavras();
        var retorno = new
        {
            Count = results.Count(),
            Results = palavras
        };        
        return Ok(retorno);
    }
    catch (Exception)
    {        
        return this.StatusCode(StatusCodes.Status500InternalServerError, "Database failure");
    }
}

O código acima retorna os registros no banco para o cliente. Se acontecer algum erro, é considerado como uma falha do servidor, retornando o código 500. Isso pois esse método get não recebe argumentos, como por exemplo o Id de uma entidade, que retornaria o NotFound(). Por conta disso, caso ocorra algum erro, é por parte do servidor. Por não existir um método para Internal server error, é utilizado o StatusCodes.

Caso o retorno fosse ActionResult, bastaria retornar com a linha return result;, que seria convertido automaticamente para um Ok().

O método acima retorna um objeto anônimo contendo a quantidade de registros no banco e a lista com os registros. Caso queiramos uma rota que apenas retorna a lista, utilizamos do ActonResult<List<Palvra>>

[HttpGet]        
public async Task<ActionResult<List<Palavra>>> Get()
{
    try
    {  
        var palavras = await _repository.GetAllPalavras();
        // Pelo retorno ser explícito, é retornado o Ok() automaticamente.
        // Caso o retorno não seja igual ao especificado, é retornado um erro.
        return retorno;
    }
    catch (Exception)
    {        
        return this.StatusCode(StatusCodes.Status500InternalServerError, "Database failure");
    }
}