Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas

Injeções via IServiceCollection

Boa noite! Seguindo mais ou menos o feeling da pergunta do Alberto (aqui), o quão "saudável" é para a aplicação a criação de, até então mostrado no curso, infinitos .AddX() para a injeção de dependências usadas tantas vezes na aplicação, tendo em vista que se quisermos criar um código fracamente acoplado, o uso da injeção se torna frequente. O que consigo imaginar no ponto atual do curso é que toda vez que o sistema crescer e precisarmos de uma injeção do tipo, iremos adicionar no Startup.Configure() e criar uma lista enorme de referências. Esse é realmente o caminho a ser tomado? Ou existem outras práticas (não necessariamente abordadas no curso) que tornam esse processo mais limpo? Caso esse ponto for abordado mais pra frente, peço desculpas por estar perguntando cedo demais hahahah

3 respostas

Olá Hudson, tudo certo?

Vamos a quantidade de .AddX(). Normalmente uma solução tem vários projetos menores que cada um deles cuida de um pedaço do sistema, a menos que o sistema seja pequeno. Então, essa lista não será tão grande assim.

Outro ponto é que, esse é o lugar onde se adiciona serviços para o projeto. Essa é uma boa prática, porque sempre que precisar adicionar ou fazer alguma alteração, é só ir diretamente onde os serviços são adicionados. Afinal, é para isso que a classe Startup.cs serve.

Espero ter ajudado!

Boa noite, Fabiano! Entendi o que você quis dizer! Mas, por exemplo (também seguindo a pergunta do Alberto), na aplicação montada no curso nós adicionamos a linha: services.AddTransient<IProdutoRepository, ProdutoRepository>(); para referenciar a injeção do ProdutoRepository. Com um crescimento da aplicação, é possível chegar a N modelos e, por consequência, N ModeloRepository. Assim sendo, continuaríamos adicionando N vezes as interfaces e implementações no Startup.cs para permitir a injeção desse modo?

solução!

Então, Hudson, mas um sistema deve fazer várias coisas, um projeto não.

Se o projeto chegar a esse tamanho, provavelmente ele está fazendo coisas demais.

Pegando a Casa do Código como exemplo, poderíamos ter toda a parte de pedidos e produtos em um projeto, um projeto só para usuários, um outro projeto só para a parte de vendas, talvez um fórum e que poderia usar os usuários do outro projeto, mas tudo que envolve o fórum, só esse projeto controla.

Então teríamos várias classes Startup.cs e cada uma delas injetaria apenas as dependências pertinentes ao projeto.

Sinceramente, não consigo encontrar uma verdadeira desvantagem em usar injeção de dependência, mesmo que precise adicionar vários serviços no Startup.cs

Advogando contra o argumento do Alberto, se esse sistema tem apenas um banco de dados com mais de 100 entidades, talvez pode ser hora de rever a complexidade deste banco e quebrar em outros bancos. Se na tabela Usuario, tem ligação com a tabela Telefones, sinceramente não acho necessário um serviço de para essa tabela. Mas claro, essa é a forma que enxergo essa situação.