BLACK FRIDAY 2024



ASP.NET Core Dependency Injection

Ao separarmos e dividirmos responsabilidades, criamos dependências e uma hora temos que resolvê-las.

É comum e viável, focarmos na resolução de um problema e ignorar o que está ao redor dele, como por exemplo nos Controllers de nossas APIs.

Lá temos a execução dos nossos fluxos, deixando de fora itens como acesso à dados por exemplo. Então é possível dizermos que um Controller não deve se preocupar com acesso à dados, isto é problema do repositório.

É possível afirmarmos também, que para uma determinada Action de um Controller funcionar, ela precisa de um Repositório, e como este repositório vai ser instanciado, ou o que ele vai fazer, não é problema dela.

Em suma, delegamos as responsabilidades. É como seu primeiro dia na empresa, onde você precisa de uma máquina para trabalhar, mas pouco importa quem ou como esta máquina chegará até você.

Dependa sempre da abstração

Em diferentes pontos da sua aplicação, você criará interfaces, que nada mais são do que contratos que somente dizem o que deve ser feito, e não como. Estas interfaces são abstrações entre o que deve ser feito e como deve ser feito.

Se você assistiu o curso 1975 - Modelando Domínios Ricos, você provavelmente percebeu que criamos interfaces para nossos repositórios, para abstrair sua implementação e podermos testá-los depois, criando versões FALSAS dele (FakeRepository).

Embora você possa fazer injeção de dependência sobre duas implementações, como mostrado abaixo:

public void Teste(MeuRepositorio repositorio) {
...
}

Se o MeuRepositorio apresentado no código acima conter outra dependência, que contém outra dependência e assim por dia, ficaria uma bagunça.

Veja este exemplo sem o uso de abstrações:

void main() {
    var command = new Command("A", "B");
    var uow = new UnitOfWork();
    var repo = new UserRepository(uow);
    var handler = new UserHandler(repo);
    var result = handler.handle(command);  
}

public class DataContext { 
    public DataContext(UnitOfWork uow) { ... }
}

public class UserRepository {
    public UserRepository(DataContext context) { ... }
}

public class UserHandler {
    public UserHandler(UserRepository repository) { ... }
}

Note que para chamar o Handler do usuário, nós precisamos primeiro do repositório, que por sua vez precisa do DataContext que por sua vez precisa do UnitOfWork.

Estas dependências são inviáveis pelo simples fato de não possuírem uma abstração, e TODA VEZ que você precisar chamar o Handler, terá todo este trabalho.

Resolvendo as Dependências

A solução para isto é justamente resolver as dependências em algum lugar, e um ótimo local para isto é ao iniciar sua aplicação.

O ASP.NET Core possui uma forma simples e direta para resolver dependências, já integrada a ele, sem necessidade de nenhum pacote adicional. Embora você possa utilizar outro framework como Ninject por exemplo.

O fato é que a resolução de dependências nativa do ASP.NET Core é boa e sustenta boa parte dos cenários. O Ninject resolve X milhões de objetos por segundo, mas espera aí... você vai precisar de tudo isso? X milhões de objetos na memória?

Sendo assim, o ASP.NET Core possui duas formas de resolver dependências:

AddScoped

É o que chamamos de Singleton, onde dado objeto/abstração A, ela será resolvida com uma instância do objeto B.

O Singleton recebe este nome por possuir apenas uma instância do objeto na memória para aquela requisição, ou seja, sempre que uma dependência desta abstração/objeto for resolvida, ela utilizará o mesmo objeto.

Este cenário é muito comum no uso de DataContexts ou DataFactories ou itens relacionados a banco de dados, onde não queremos ter mais de uma conexão por requisição. Sendo assim, dada a primeira resolução de dependência do seu DataContext, as próximas farão uso do mesmo objeto, que ficará na memória enquanto a requisição estiver viva.

Ao término da requisição o GC se encarrega de remover os objetos da memória.

AddTransient

Diferente do Singleton, no AddTransient, para cada resolução de dependência, temos um novo objeto, ideal para cenáriosonde você não quer reaproveitar nada.

Código

Tanto o AddScopped quanto o Addtransient são utilizados no Startup.cs da sua API, como mostrado no código abaixo:`

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    
    services.AddScoped<StoreDataContext, StoreDataContext>();
    services.AddTransient<ProductRepository, ProductRepository>();
}

Note que utilizamos o DataContext com AddScopped pois ele manterá as conexões com bancos de dados e também as transações, e não queremos múltiplas conexões ou transações abertas caso haja necessidade de chamá-lo em mais de um lugar.

Já o ProductRepository ficou com AddTransient, pois não necessitamos manter estado de nada dentro dele, ou seja, a cada injeção dele, será uma nova instância.

Injetando objetos nos Controllers

Com as dependências resolvidas, podemos injetar objetos de duas formas nos Controllers, sendo elas via FromServices ou manualmente.

Injetando Manualmente

No exemplo abaixo, fazemos a injeção manual, onde temos uma propriedade, normalmente privada e somente leitura, que recebe a instância do nosso objeto.

public class ProductController : Controller
{
    private readonly IProductRepository _repository;

    public ProductController(IProductRepository repository)
    {
        _repository = repository;
    }

    [Route("v1/products")]
    [HttpGet]
    public IEnumerable<ListProductViewModel> Get()
    {
        return _repository.Get();
    }
}

Posteriormente, no construtor da classe, fazemos a injeção de dependência, que será resolvida pelo ASP.NET Core, gerando a instância do nosso objeto.

Para finalizar, passamos a instância do objeto gerado para nossa propriedade privada, finalizando o processo.

FromServices

Há também uma forma mais limpa de injetar nossas dependências nos Controllers, utilizando o FromServices como no código abaixo:

public class ProductController : Controller
{
    [Route("v1/products")]
    [HttpGet]
    public IEnumerable<ListProductViewModel> Get([FromServices]IProductRepository repository)
    {
        return repository.Get();
    }
}

Ao adicionar o FromServices a um parâmetro em algum método do seu Controller, o ASP.NET Core automaticamente buscará nas dependências (AddScopped, AddTransiente) suas implementações e fará a resolução.

O legal desta forma é que economizamos várias linhas de código e deixamos os Controllers mais limpos.

Conclusão

Criar dependências é algo que está cada vez mais comum nas aplicações, mas a conta uma hora chega. Que bom que e o ASP.NET Core facilita muito a resolução de dependências já nativamente, sem necessidade de nenhum framework externo.

Populares

Priority Queue

Priority Queue ou fila prioritária é um tipo de lista inclusa no C# 10 que permite que seus itens...


Implicit Operators no C#

Implicit Operators permitem adicionar comportamentos de conversão a objetos Built In ou complexos...


ASP.NET 5 – Autenticação e Autorização com Bearer e JWT

Este artigo atualmente utiliza a versão 5.0.0-rc.1 do ASP.NET/.NET, o que significa que ainda não...


Clean Code - Guia e Exemplos

Saiba como manter seu código limpo (Clean Code) seguindo algumas práticas sugeridas pelo Robert C...


Git e GitHub - Instalação, Configuração e Primeiros Passos

Git é um sistema de controle de versões distribuídas, enquanto GitHub é uma plataforma que tem o ...


Compartilhe este artigo



Conheça o autor

Me dedico ao desenvolvimento de software desde 2003, sendo minha maior especialidade o Desenvolvimento Web. Durante esta jornada pude trabalhar presencialmente aqui no Brasil e Estados Unidos, atender remotamente times da ?ndia, Inglaterra e Holanda, receber 8x Microsoft MVP e realizar diversas consultorias em empresas e projetos de todos os tamanhos.





2.926

Aulas disponíveis

275

horas de conteúdo

71.663

Alunos matriculados

49.780

Certificados emitidos





Comece de graça agora mesmo!

Temos mais de 20 cursos totalmente de graça e todos com certificado de conclusão.

Começar


Prefere algo mais Premium?

Conheça nossos planos



Premium anual

Compra única, parcelada em até
12x no cartão de crédito


12x R$

84

,78

=R$ 1.017,36
  • 1 ano de acesso
  • Acesso à todo conteúdo
  • Emissão de Certificado
  • Tira Dúvidas Online
  • 61 cursos disponíveis
  • 10 carreiras disponíveis
  • 161 temas de tecnologia
  • Conteúdo novo todo mês
  • Encontros Premium

Começar agora

Política de privacidade



Precisa de ajuda?

Dúvidas frequentes



  • Posso começar de graça?

    Sim! Basta criar sua conta gratuita no balta.io e começar seus estudos. Nós contamos com diversos cursos TOTALMENTE gratuitos e com certificado de conclusão.

  • Vou ter que pagar algo?

    Nós temos cursos gratuitos e pagos, porém você não precisa informar nenhum dado de pagamento para começar seus estudos gratuitamente conosco. Os cursos gratuitos são completos e com certificado de conclusão, você não paga nada por eles.

    Porém, caso queira algo mais Premium , você terá acesso à diversos benefícios que vão te ajudar ainda mais em sua carreira.

  • Por onde devo começar?

    Siga SEMPRE as nossas Carreiras , elas vão te orientar em todos os sentidos. Os cursos já estão organizados em categorias e carreiras para facilitar seu aprendizado.
    Nossa sugestão para aprendizado é começar pelo Backend e seguindo para Frontend e Mobile.

    • Backend
    • Frontend
    • Mobile

  • Os cursos ensinam tudo que preciso?

    Nenhum curso no mundo vai te ensinar tudo, desculpa ser sincero! Os cursos são uma base, eles fornecem por volta de 30% do que você precisa aprender, o resto é com você, com dedicação e MUITA prática.

  • O que eu devo estudar?

    Java ou .NET? Angular ou React? Xamarin ou Flutter? A resposta é simples e direta: "Você já sabe o básico?"

    Se você ainda não sabe BEM o básico, ou seja, os fundamentos, OOP, SOLID, Clean Code, está perdendo tempo estudando Frameworks ou até coisas mais avançadas como Docker. Foque nos seus objetivos primeiro.
    Agora se você está indeciso sobre qual Framework estudar, a boa notícia é que o mercado neste momento está bem aquecido e você tem várias oportunidade. Desta forma o que levaríamos em conta para tomar esta decisão seria:

    • Já sei o básico
    • O Framework/Tecnologia tem mercado onde eu estou (região)
    • O Framework/Tecnologia é utilizado em uma empresa onde quero atual
    • O Framework/Tecnologia resolve meu problema
    • Eu gosto de utilizar o Framework/Tecnologia

  • Estou pronto para estudar no balta.io?

    Com certeza! O primeiro passo é começar e você pode fazer isto agora mesmo!

    Começar de graça

Ainda tem dúvidas?





Assine nosso Newsletter

Receba em primeira mão todas as nossas novidades.

Cadastrar


balta.io