Vi na InfoQ um artigo intitulado: Does Dependency Injection pay off? Nesta URL.
Um comentário contido nele me foi curioso:
Ou seja, o cara diz que só ficou popular pq a galera usa para fazer testes unitários.
Eu não utilizo DI embora tenha lido uma coisa ou outra a respeito. Mas gostaria de saber de vocês( e isso vai ser muito enriquecedor para mim). Para quê você usa Injeção de Dependência(Dependency Injection)?
Nós usamos para fazer aplicações orientadas a plugins (aqui falando mais de IoC) e testes unitários.
Mas a grande questão também é… não são os testes unitários um benefício grande o suficiente para justificar a DI?
Em contextos do tipo statefull isso é quase obrigatório para o programador não ficar repetindo código para pegar os beans da seção. Porém, nesse caso não é muito útil sem bijeção, ou seja, além de injetar as dependências também tem que “ejetar” (aplicar as alterações feitas sobre bean pela action).
Mas, nesse caso, pq outros padrões não seriam igualmente úteis. Entre eles strategy, registry ou, como cita o autor do artigo original, o provider?
Mas, nesse caso, pq outros padrões não seriam igualmente úteis. Entre eles strategy, registry ou, como cita o autor do artigo original, o provider?[/quote]
No Registry acho que ainda é necessário acessar o locator para pegar a implementação, já no caso da DI isso não é necessário.
IMO, acredito que DI pegou carona na popularidade do spring na época do embate forte com ejbs.
Mas quem pensa que para fazer testes unit´parios precisa de DI está completamente enganado, eu não estou usando DI apenas por restricoes besta do cliente, por mim usuaria… :?
Mas testes unitários… isso sim é indispensável.!
O fato é que muita coisa tem virado “modinha” ultimamente.
Tem gente que fala “usa DI e spring” ou “usa struts e MVC” sem saber do que está falando. Só repete o que viu nos fóruns por aí e não leva em consideração trade-offs de diversas tecnologias.
Para quem não viu que tinha um link no post da URL, acho que vale a pena ler o artigo original:
http://scruffylookingcatherder.com/archive/2007/08/07/dependency-injection.aspx
Onde o autor realmente defende bem a idéia. O que achei importante nisso tudo é que ele levanta o questionamento. Até onde DI vale a pena? O quanto devemos abrir mão das práticas de projeto que a DI nos tira? E, existem soluções ainda melhores que a DI?
Essas são perguntas que um programador prudente não pode deixar de fazer. E não só para DI, como para todas as tecnologias.
Não estou dizendo que DI é ruim, nem que tem que ser abandonado. Pelo contrário, ela tem se provado uma ótima alternativa, especialmente pq os processos ágeis tem como um dos seus pilares os testes unitários.
Só venho defendendo ha um bom tempo aqui que nós devemos saber exatamente os prós e os contras de cada solução. Fabricantes de frameworks vão tentar te convencer que os paradigmas que eles adotaram são a cura para todos os seus males. E isso nunca é verdade.
[quote=ViniGodoy]
Só venho defendendo ha um bom tempo aqui que nós devemos saber exatamente os prós e os contras de cada solução. Fabricantes de frameworks vão tentar te convencer que os paradigmas que eles adotaram são a cura para todos os seus males. E isso nunca é verdade.[/quote]
Claro, concordo com você. Avaliando o exemplo que tinha dado de statefull, já ouvi casos de empresas que tem que ficar reiniciando servidor de madrugada por causa da quantidade de objetos do contexto que ficam alocados (e perdidos) em memória.
O problema é que os conceitos já vem encapsulados dentro dos frameworks, pois a indústria quer facilitar. O preço da abstração é a dificuldade de saber o que está de baixo dos panos. Por isso sempre vai existir programador e usuário.
Blz. É uma boa a discussão que vocês estão tendo. E esse é um dos meus objetivos ao abrir esse tópico. Mas gostaria que os demais usuários do guj que usam DI colocasem para que a têm usado em seus projetos.
Isso enriquecerá mais ainda o tópico (e a mim também) 
O que quer dizer isso, de orientada a plugin?
Se a aplicação possuir ou necessitar de um modelo voltado a componentes acho válido a utilização de DI.
Eai Pessoal,
Eu uso DI com o objetivo de obter um maior desacoplamento… agora o resultado disso é que ficou muito fácil pra criar mocks pros testes unitários, o que prova que código que segue as boas práticas de OO é fácil de testar .
[]s
Ferry
O que quer dizer isso, de orientada a plugin?[/quote]
Acho que ele estava se referindo a OSGI
Modelo voltado a componentes? Isso me parece coisa de .NET…
Modelo voltado a componentes? Isso me parece coisa de .NET…[/quote]
Componentes, Serviços, etc. Os nomes podem ser os mais variados. Mas a utilização do conceito não depende de plataforma.
Plugins são componentes feitos para serem acoplados a sua aplicação depois do código já compilado.
Eles precisam ser ainda mais desacoplados do que um modelo de componentes tradicional, pois não se sabe o que um terceiro, implementador do plugin, vai querer colocar por lá.
Acho que é esse mesmo o questionamento do autor do artigo. Por que você usa DI e não outro padrão qualquer? Existem vários padrões (muitos deles mais simples) que geram desacoplamento (ele mesmo cita um exemplo com o provider no artigo).
Ou o motivo é só por causa dos testes unitários?
Eu vou admitir.
Um dos grandes motivos pelo qual eu uso DI são, exclusivamente, os testes unitários.
O outro é pq é conveniente. Como uso muito o spring, acabo usando DI pq o spring foi feito para trabalhar com ela.
Aliás, que bom que alguém citou o Fowler. Já notou que ele mesmo diz na descrição do padrão:
"Inversion of control is a common feature of frameworks, but it’s something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn’t to say it’s a bad thing, just that I think it needs to justify itself over the more straightforward alternative.
Está começando a melhorar. Pena que poucos aqui, como o Vini, estão postando sua experiência própria e a razão pela qual estão utilizando DI.
Quem utiliza DI, posta ae sua experiência vá lá 
Correto! Concordo com vc… mas esse termo “Modelo de Componentes” é bastante utilizado pelo pessoal de .NET focados em orientação a eventos e os seus “maravilhosos” componentes e controllers por componente…