Eu pessoalmente não estou usando, muito por causa de restrições de ambiente e performance. Vi alguns amigos (arquitetos) pulando pra dentro do Spring (convencidos pela galera aqui do guj e pelo tio Rod) e alguns desses quebraram a cara, não no debug, mas no treinamento da galera que daria manutenção. IoC é um assunto muito extenso, a grande maioria dos desenvolvedores ainda nem sabe desenvolver bem com OO pura e simples, vixe maria!!!
Meus testes unitários são sacais, tá tudo muito amarrado, concordo que esses poderiam melhorar bastante só pelo fato de usar um framework IoC mas não acho que pro me caso isso justifique.
[quote]Vi alguns amigos (arquitetos) pulando pra dentro do Spring (convencidos pela galera aqui do guj e pelo tio Rod)[/quote][/quote]Vc. vai ter que ser mais objetivo nesse “convencidos pela galera aqui do guj”.???
[quote]mas no treinamento da galera que daria manutenção.[/quote]Então o problema foi outro.
A aplicação que utilizei como base para a minha medição foi uma aplicação utilizando Spring com Hibernate. O pessoal que desenvolveu essa aplicação usou os templates do spring pra hibernate e tal mas eles não tinham grandes conhecimentos de hibernate SQL (IMO, seis meses atrás) - não sei se tinham pro Spring, não olhei o código à fundo. Sei que, dado o tempo que EU tinha pra avaliar o risco decidi por não por minha bunda na janela (fora o fato de não ter uma equipe com skill “real” pra dar manutenção IoC/Spring).
Concordo que minha afirmação inicial dá idéia, incorreta, de quê o problema de performance que mencionei era puramente do Spring (IoC), mas medi o que tinha em mãos na época. Antes de decidir por não utilizar percorri a web em busca de opiniões diversas e encontrei algumas reclamações de performance específicas pro Spring (principalmente para aquelas aplicações com grande números de classes injetadas). Não fui a fundo no assunto.
Para o meu caso, até agora, Spring não vai ajudar muito. Trabalho, hoje, numa fábrica onde a maioria do pessoal é júnior e quando o cara ganha algum skill novo ele acaba pulando fora para uma proposta melhor. Se eu optar por usar Spring nesse ambiente terei de adicionar no meu risco a provável incapacidade técnica tanto minha quanto da minha equipe, para, no tempo dado, levar esses projetos até o final.
Como disse antes: nossos testes de unidade são muito simples, amarrados, mas simples. Os de integração quase nem existem. Pode ser que, num futuro bem longe de onde estou hoje (empresa) eu use Spring da forma como ele merece - mas hoje ele não se justifica pra minha realidade.
Quanto à restrição de ambiente foi algo bem específico: nosso cliente (vale) simplesmente não “permite” a utilização de “frameworks” não homologados.
IoC = Inversão de Controle = ao invés de suas classes decidirem por si só quais implementações elas irão utilizar, isso é configurado num lugar central. O caso clássico são os DAOs ou Repositórios.
Todas as suas classes vão utilizar um userDAO (interface) e o container de IoC vai injetar a implementação que vc deseja em todas elas, por exemplo um OracleUserDAO. Se amanhã vc quiser trocar a implementação para DummyUserDAO, por exemplo para testes, vc pode muito facilmente e comodamente fazer isso, alterando apenas uma linha de código nas suas configurações.
AutoWiring = DAOs precisam de Connection, ou Session do Hibernate, ou DataSource, ou sei lá o que… É muito comodo vc definir em apenas um lugar que o que precisar de uma connection vai receber uma connection e pronto. O trabalho sujo de ligamento e injeção é o container/framework que faz isso pra vc.
IoC e Autowiring promovem um belo desacoplamento, facilitam a manutenção, evolução, separação de responsabilidades e promovem um melhor entendimento do sistema, ao meu ver. Não é algo ESSENCIAL/FUNDAMENTAL, mas é uma bela boa prática hoje em dia. Se o framework que vc está usando suporta IoC/DI/Autowiring, então seria bem recomendável que vc faça uso desses recursos.
Eu gostaria muito da experiência pessoal de todos, sobretudo os mais antigos daqui sobre em que contexto e com que objetivo utilizaram isso. Esse é o principal objetivo do tópico.
pcalcado, saoj, vcs não gostariam de falar da experiência de vocês?
Vini, entre outros, fez isso. Achei massa e tá enriquecendo muito.
DI existe pois Java é uma linguagem muito fraca quando o assunto é abstração. Não é possivel criar qualquer forma de abstração sobre tipos, tão pouco é possivel criar sistemas realmente paramétricos. Não existe real motivo para não usar new diretamente, o problema é que não existe uma construção de instanciação paramétrica, e tão pouco existe o conceito real modulos, só existem namespaces.
Linguagens como NewSpeak permitem construção de modulos paramétricos os quais podem ser instanciados com suas dependencias informadas. É simples e intuitivo, módulos não são permitidos terem dependencias externas fixas, todas tevem ser paramétricas.
DI é apenas uma gambiarra para resolver mais um dos problemas de uma linguagem pobre.
[quote]agodinhost wrote
Pra esse exemplo eu concordo, mas vc realmente acha que eu preciso de Spring pra todo tipo de aplicação?[/quote]Não, há outros recursos e digo o mesmo para o hibernate. Agora uma coisa é certa, há muita gente da área de TI usando ferramentas, frameworks etc. pela frequencia com que os assuntos são gerados pelos foruns. Alguns em sua maioria nem sabem se a ferramenta é adequada ao projeto, mais vc. colocou alguns pontos interessantes que devem ser reavaliados em um projeto.
sds.
Já no início, programadores ouvem que é uma boa prática desenvolverem para interfaces… “abstração” é a palavra da ordem (o sistema “pode” mudar de implementação em determinado serviço, mudar de frameworks e etc ).
O próximo passo é como abstrair: o coração disso…“Factories”.
Então, com embasamento e as “motivações” propostas pelos gurus dos Design Patterns (gambiarras catalogadas para suprir deficiências semânticas ou de paradigmas), surgem os mais diversos nomes e códigos para garantir que seu sistema saia o mais burocrático, extensível e “abstrato” do mundo.
Então você vaga pela internet, encontra um Portal de malucos falando sobre Injeção de Dependência e resolve ler um pouco mais a respeito:
“Hey, mas peraê, ca-ca-ca-cadê os sssingletons nas classes de vocês? Suas AbstractFactories e seus respectivos produtos-fábricas? Onde vocês estâo gerenciando/instanciado estas interfaces? Vocês não precisam se preocupar com nada disso, tão de sacanagem comigo? E ainda por cima isso facilita o desenvolvimento seus Testes Unitários?”
Mais ou menos. O modo como os frameworks fazem em Java tenta vencer limitações da linguagem mas ter sas dpeendências fornecias or alguém automaticamente é algo válido em muitas linguage,s boas e ruins.
[quote=louds]DI existe pois Java é uma linguagem muito fraca quando o assunto é abstração. Não é possivel criar qualquer forma de abstração sobre tipos, tão pouco é possivel criar sistemas realmente paramétricos. Não existe real motivo para não usar new diretamente, o problema é que não existe uma construção de instanciação paramétrica, e tão pouco existe o conceito real modulos, só existem namespaces.
Linguagens como NewSpeak permitem construção de modulos paramétricos os quais podem ser instanciados com suas dependencias informadas. É simples e intuitivo, módulos não são permitidos terem dependencias externas fixas, todas tevem ser paramétricas.
DI é apenas uma gambiarra para resolver mais um dos problemas de uma linguagem pobre.[/quote]
Louds, na boa, diversos tópicos que o pessoal fala de utilização de algum conceito, você mete o pau na linguagem. Já até comparou com C#, pois agora está envolvido com mono e etc…
Agora vem falar de NewSpeak, what’s fuck is this ? Linguagem para os computadores do Império ou Naboo ?
Falar que a linguagem é fraca, não possui o conceito de módulos como em Ruby, são retóricas já conhecidas. Acho que mentes como a sua deveriam trabalhar em prol e não só no ponto crítico.
Talvez entrar numa comissão ou definir algumas JSR´s abocanharia muito mais mercado que o mono.
É fácil sair criticando à todo momento, difícil é ajudar a consertar.
O que estou achando engraçado é que muita gente está repetindo o que leu sobre IoC. Mas não está falando porque usam IoC no lugar do padrão provider, por exemplo. O fato é que a maior parte dos argumentos em prol do IoC também é fornecido por outros padrões, muitos deles mais simples, que nem exigiriam algo pesado como um framework inteiro por trás.
Já se perguntaram se existem outros padrões melhores ou mais simples que IoC?
Eu reforço a pergunta. Acho que a menos que você tenha um loop muito intenso onde objetos são criados, a reflexão de um framework de DI não será um problema. Eu também gostaria de saber onde isso se torna um gargalo para uma aplicação.
Segundo os mais puristas, qualquer padrão de projeto é uma gambiarra para resolver um problema de uma linguagem pobre. Até por isso a “gangue dos quatro” foi julgada e condenada pelo livro de padrões de projeto.
O fato é que, pobre ou não, a linguagem resolve diversos outros problemas e é popular hoje em dia. Muitas linguagens (como a própria NewSpeak, citada por você) ainda não tem nem a maturidade, nem o time de empresas dando suporte que o Java tem e, embora sejam conceitualmente interessantes, não duvido que apresentarão diversos problemas a medida que a comunidade de programadores crescer e se desnvolver… e então, surgirão outros padrões para elas…
Ok, isso é só uma constatação, não uma desculpa. Linguagens assim devem existir e devem se desenvolver e, provavelmente, devem substituir o Java no futuro. Só que o gap entre o uso de uma tecnologia e o surgimento de uma nova que efetivamente a substitua, merece os padrões e frameworks do mercado.
Desses quatro conceitos que envolvem o IoC, o mais crítico para performance é Lifecycle Support.
No JSF por exemplo pode ser definido o scopo das requisições, além do request normal, também têm opções como Session e Application. O problema é que a forma como isso é gerenciado é sempre um mistério, ou seja, não da pra saber como é feita a coleta de lixo, ou garantir que isso realmente seja feito.
Mais ou menos. O modo como os frameworks fazem em Java tenta vencer limitações da linguagem mas ter sas dpeendências fornecias or alguém automaticamente é algo válido em muitas linguage,s boas e ruins.[/quote]
Meu ponto não era sobre ter ou deixar de ter as dependencias fornecidas por alguém automáticamente. Mas pelo fato de que isso não é parte integral da linguagem. Basta uma linguagem que suporte instanciação de módulos com parâmetros, isso resolve todos problemas que DI tenta e ainda tem vários benefícios extras, como permitir mixins com as dependencias.
Mais ou menos. O modo como os frameworks fazem em Java tenta vencer limitações da linguagem mas ter sas dpeendências fornecias or alguém automaticamente é algo válido em muitas linguage,s boas e ruins.[/quote]
Meu ponto não era sobre ter ou deixar de ter as dependencias fornecidas por alguém automáticamente. Mas pelo fato de que isso não é parte integral da linguagem. Basta uma linguagem que suporte instanciação de módulos com parâmetros, isso resolve todos problemas que DI tenta e ainda tem vários benefícios extras, como permitir mixins com as dependencias.[/quote]
Boa seria auxiliar o pessoal que está desenvolvendo as JSR´s para o Java 7, assim contribuiria para a evolução da linguagem, ao invés de deixá-la ir pro abismo
Em uma linguagem baseada em trocas de mensagens, nenhum aparente. Principalmente pelo fato de ser dificil diferenciar parametricidade e dependent types. Provavelmente o maior problema venha com a criação de módulos muito grandes que teriam um construtor enorme. Autowiring também não seria tão obvio nesses casos.
Em uma linguagem OO com dispatch explícito, feito java, não tenho a menor idéia, mas o impacto é semelhante ao de usar generics, porém com o uso de dependent types, o sistema de tipos tente a ficar uma zona. C++ é um exemplo disso, introduzir tipagem segura na linguagem seria muito complicado.
