Na parte 1 desta série falamos sobre como funciona a injeção de dependência e até criamos um exemplo usando NInject. um famoso mecanismo de DI (depency injection).
Neste artigo vamos falar como o ASP.NET Core revolucionou a injeção de dependência, incorporando este mecanismo ao seu núcleo. Isto significa que agora já temos o mecanismo nativamente implementado, sem a necessidade de uma ferramenta de terceiros.
Uma outra coisa interessante sobre este mecanismo no ASP.
Olá,
Hoje em dia muito se tem se falado muito em injeção de dependência, principalmente se você desenvolve ou está começando a desenvolver com ASP.NET Core.
Mas que realmente significa “injetar” uma dependência e o que é a tal dependência?
Conceito Injeção de dependência é um padrão de projeto que permite baixo acoplamento do código!
Ai você se pergunta, mas o que é acoplamento do código? Sendo bem simplista, é um código que possui uma alta dependência de um outro código, onde o relacionamento entre os dois é muito forte!
Você é do tipo que as vezes muda o conteúdo de uma view no ambiente de produção ?
Isto pode ser algo “questionável”, mas é também muito útil se você precisa fazer um pequeno ajuste na parte visual na aplicação.
Eu já precisei mudar códigos JavaScript nas páginas em uma aplicação onde não poderia executar uma nova publicação, e esta facilidade me poupou muito tempo!
Mas uma mudança feita no ASP.
Se você desenvolve em .NET provavelmente já se perguntou se tudo o que é preciso para a sua aplicação funcionar está na pasta de publicação, certo ? Normalmente temos dezenas, as vezes centenas de DLLs que precisamos levar para o ambiente de produção, e esquecer uma delas pode ser um caos total!
Bom, se você já está desenvolvendo para .NET Core isto está sendo resolvido de uma forma muito interessante: Bem vindo ao Self Contained App.
Nestes tempos de migrações e vários Frameworks, é comum termos aplicações feitas em várias versões, desde o .NET Framework até as mais recentes versões do .NET Core.
Em um cenário ainda mais complicado, temos códigos produzidos em varias versões do mesmo framework, por exemplo: 3.0, 3.5,4.0, 4.5, etc. Mas e quando precisamos verificar se uma determinada DLL ou até mesmo um EXE estão na versão do framework que precisamos ? Qual o caminho ?
Sempre que vou falar sobre versionamento de código em alguma empresa ou evento, eu pergunto para os “caras do TI” (IT Pros), como eles guardam os scripts para trabalhar em servidor, banco de dados, etc. A resposta é muito parecida e sempre curiosa: “Eu guardo lá em um HD no meu PC”, ou seja, tá na minha máquina de trabalho, no máximo em um Drive de Nuvem.
Pergunto também se eles controlam as mudanças feitas nestes scripts e outro dia recebi uma resposta curiosa: “Eu controlo as mudanças em uma planilha!
Esta semana aconteceu algo interessante. Tenho um projeto hospedado em um host, que por sinal é muito eficiente, mas me surpreendeu quando perguntei se eles suportavam ASP.NET Core!
A resposta foi “nosso técnico disse que o ASP.NET Core ainda não é estável”
Isto me deixou surpreso e ao mesmo tempo intrigado, pois a plataforma .NET Core já existe há alguns anos e vem melhorando e supreendendo a cada dia! Basta olharmos os números!