Arquivo Discussoes de Programacao e Tecnologia 
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?
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.
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.
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?
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…
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…
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.
Que problemas de performance Dependency Injection tem te dado?
agodinhost wroteVc. vai ter que ser mais objetivo nesse “convencidos pela galera aqui do guj”.???Vi alguns amigos (arquitetos) pulando pra dentro do Spring (convencidos pela galera aqui do guj e pelo tio Rod)
mas no treinamento da galera que daria manutenção.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.
Preciso mesmo? A galera aqui do guj defende o spring como se ele fosse a nona maravilha do mundo (a oitava agora é o cristo certo?)
Pra esse exemplo eu concordo, mas vc realmente acha que eu preciso de Spring pra todo tipo de aplicação?
Minha visão disso é:
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.
agodinhost wroteNã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.
Pra esse exemplo eu concordo, mas vc realmente acha que eu preciso de Spring pra todo tipo de aplicação?
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?”
É, eu acho DIP uma boa …
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.
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.
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.
[]´s
K.
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.
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.
1 Control of instantiation (constructor) and setter based injection of managed objects.
2 Dependency Handling
3 Lifecycle Support
4 Configuration Support
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.
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.
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.
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
E que problemas isso cria?
E que problemas isso cria?
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.
Qual linguagem tirando a exótica já citada oferece isso?
Alias, não entendi uma coisa: imaginando que instanciação de módulos com parâmetros seja algo como declarar as dependências de um módulo no corpo do código e e runtime obtêr esta dependências isso é Depency Injection, só que feito pelo runtime da linguagem ao inves de um container opcional, não? Se for (não estou dizendo que seja) não vejo tana vantagem, injeção pode não ser a melhor escolha e poder optar por um outro outro é melhor. e eu quiser um modelo que tenha DI fácil eu poso desenvolver para um container específico.
Eu concordo, entretanto, que os containers DI tendem a produzir configuracões bem extensas.
1 Control of instantiation (constructor) and setter based injection of managed objects.
2 Dependency Handling
3 Lifecycle Support
4 Configuration Support
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.
O link deu 404 e não ntendi ua resposta. Controle de ciclo de vida é o problema que você tem? Ou ele causa o problema? Que problema, então?
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.Cara, já respondi e te adianto que estou longe de ser expert no assunto. Pesquisei na web e fiz medições de uma aplicação em produção que em teoria deveria ser “modelo de referência” e, pessoalmente, não gostei dos resultados (Sejam esses por causa do hibernate/spring template ou devidos à uma técnica ruim).
Agora vamos simplificar e “imaginar” o seguinte cenário e me diz o quê vc acha:
Tenho duas versões da mesma aplicação, uma utilizando spring e outra não, escritas com o mesmo nível de qualidade e que fazem muito acesso a banco e fazem muito cálculo (modelos econométricos, VARM, VECM). Todos esses cálculos são feitos em séries (mensais) para 30 anos.
Essa aplicação tem umas 10 entidades pra CRUD e todo o restante é calculo.
Quem vc acha que vai ser mais rápido?
Preciso mesmo de Spring pra esse tipo de aplicação? Porquê? Quais benefícios?
Meus testes principais estão focados nos cálculos.
ViniGodoy, só mais um detalhe: formei minha opinião ouvindo outros colegas no mercado, analisando minha situação e trocando idéias.
Spring é, na minha opinião, 10, um super framework que promete muito, muito mesmo (ainda mais agora com o Spring Integration!!!) mas eu não acho que nosso nível técnico, generalizando o mercado atual, esteja pronto. Apenas um parco gato pingado está apto a realmente utilizar esses frameworks da forma adequada e mais ainda decidir ONDE eles realmente podem ou devem ser aplicados.
Pior de tudo: quando vc acha um recurso que conhece o framework ele já está alocado ou não tem os pés no chão. Já vi currículo de arquiteto com menos de 2 anos na função querendo 8 pratas simplesmente (meu achômetro) porquê tinha “frameworks” de “ponta” listados.
Dificilmente o uso de DI/IoC, eja Spring ou não, vai impactar na performance em um ponto perceptível. O úico aspecto que o Sprin iria se envolver ia ser na criaçao e wirin de componentes, que é feito geralmente uma vez apenas.
Acho que você está culpando o componente errado do sistema.
Os benefícios certamente estão em qualquer página que fale sobre Sprin, se valem a pena ou não no seu caso e outra coisa que não pode ser respondida aqui.
Apesar de DI não ser sobre testes, uma aplicação deve ser testada como um todo e não apenas em partes específicas então você tem que se preocupar com testes em outros lugares também.
Você conhece seu sistema melhor do que eu… quem sou eu para dizer que você precisa do Spring? Aliás, não é sobre isso que tenho falado desde o início? Que a gente tem é que pesar os benefícios/desvantagens? Você parece que pesou bem e, se sua conclusão foi essa, boa sorte!
Eu mesmo já desprezei o spring por ter aplicações onde o .jar deveria ser pequeno e eu não queria uma biblioteca gigantesca acoplada. Um motivo simples, mas que justificou plenamente o não-uso.
Dificilmente o uso de DI/IoC, eja Spring ou não, vai impactar na performance em um ponto perceptível. O úico aspecto que o Sprin iria se envolver ia ser na criaçao e wirin de componentes, que é feito geralmente uma vez apenas.“Geralmente” uma vez? OK, Spring então é mais rápido que java puro e simples? Não há reclamações da performance do Spring?
Apesar de DI não ser sobre testes, uma aplicação deve ser testada como um todo e não apenas em partes específicas então você tem que se preocupar com testes em outros lugares também.Isso parece cópia do discurso do cv, desculpe. Estou careca de saber disso, mas na prática vc tem verba pra realmente escrever testes pra todo o sistema? Eu, pessoalmente, elenco o que é relevante e mais importante dentro do meu orçamento. Mas isso sou eu. A questão é custo x benefício.
Aliás, não é sobre isso que tenho falado desde o início? Que a gente tem é que pesar os benefícios/desvantagens?Perdão, achei que vc estava só questionando. Estamos de acordo.
“Geralmente” uma vez? OK, Spring então é mais rápido que java puro e simples? Não há reclamações da performance do Spring?
Ahm? De onde voceê inferiu isso? Você instanciaria um componente mais de uma vez? para quê? Componentes com estado?
Isso parece cópia do discurso do cv, desculpe. Estou careca de saber disso, mas na prática vc tem verba pra realmente escrever testes pra todo o sistema? Eu, pessoalmente, elenco o que é relevante e mais importante dentro do meu orçamento. Mas isso sou eu.
Sim, tenho. Tanto aqui quanto no meu emprego anterior. Se você consegue mostrar valor em boas práticas você consegue aplicá-las, se não consegue mostrar valor e preferir viver no seculo passado bem… boa sorte.
Ahm? De onde voceê inferiu isso? Você instanciaria um componente mais de uma vez? para quê? Componentes com estado?Reinicialização de server por exemplo, clusters, farms, coisas assim.
Sim, tenho. Tanto aqui quanto no meu emprego anterior. Se você consegue mostrar valor em boas práticas você consegue aplicá-las, se não consegue mostrar valor e preferir viver no seculo passado bem… boa sorte.E vc fez isso tudo do dia pra noite?
Quantas vezes você reinicia seu servidor por semana?
Não, mas o primeiro passo foi saber onde eu estava e onde queria chegar. Dizer que boas práticas estão fora da realidade não ajuda.
Quantas vezes você reinicia seu servidor por semana?Depende muito do cliente, tenho um caso em especial (o mais recente, vale) que os caras inicializam o server de produção mais de 6 vezes por dia. Não sei dizer quantas aplicações estão nesse server, mas nos exigiram que a aplicação não levasse mais que 5 minutos pra levantar. Nem pensei em questionar esse requisito pois já vi algumas aplicações que levavam duas horas pra levantar (isso mesmo, duas horas, dentro da fábrica da IBM, a aplicação usava entity beans e havia sido mal dimensionada). Fico imaginando uma aplicação Spring com muiiiiittaaaassssssss classes.
Não, mas o primeiro passo foi saber onde eu estava e onde queria chegar. Dizer que boas práticas estão fora da realidade não ajuda.Perdão, mais uma vez, não disse que boas práticas estão fora da realidade. No máximo que Spring está fora da “minha” realidade atual, infelizmente. Mas não creio que usar Spring seja sinônimo de utilizar boas práticas, sry.
Depende muito do cliente, tenho um caso em especial (o mais recente, vale) que os caras inicializam o server de produção mais de 6 vezes por dia. Não sei dizer quantas aplicações estão nesse server, mas nos exigiram que a aplicação não levasse mais que 5 minutos pra levantar. Nem pensei em questionar esse requisito pois já vi algumas aplicações que levavam duas horas pra levantar (isso mesmo, duas horas, dentro da fábrica da IBM, a aplicação usava entity beans e havia sido mal dimensionada). Fico imaginando uma aplicação Spring com muiiiiittaaaassssssss classes.
Eu perguntei mais or curiosidade. Eu acredito que um ambiente assim possui aguns problemas arquiteturais e de infra-estrutura, dificilmente isso seria normal, mas tudo bem, não é um problema que o impediria, se você quiser, de usar Spring. O tempo gasto na leitura de um appContext é irrisório e instancia’ão via reflection é muito rápida (ou então nada em Java EE iria funcionar), não vejoe ste cenário como problemático. Insisto: provavelmente o problema está na aplicação e não no framework. Já desenvolvi com Spring para aplicações desktop e estes cenários ossuem um número de restarts muito alto, mesmo assim nunca foi problema (na verdade, o problema sempre foi o bootstrap da JVM).
Spring? Eu não estava faando de Spring, estava falando de testes, que foi sobre o que você falou “não ter orçamento”.
Eu perguntei mais or curiosidade.OK. Vou ter chance de dar uma reavaliada nisso tudo logo logo. Como disse anteriormente não fui a fundo. Com certeza ainda volto a te pentelhar com esse assunto.
Spring? Eu não estava faando de Spring, estava falando de testes, que foi sobre o que você falou “não ter orçamento”.Mea culpa. O mais triste é que quando digo pro meu gerente que preciso de 4 horas pra escrever os testes unitários de algum treco ele nem dá bola …
Nem todo mundo trabalha na plimplim.com shoes, muito menos estou na Austrália (por enquanto, mas vai ser canadá)
valeu.
Só uma perunta ra fechar, quantos % das suas classes eram Spring beans?
Mea culpa. O mais triste é que quando digo pro meu gerente que preciso de 4 horas pra escrever os testes unitários de algum treco ele nem dá bola …Nem todo mundo trabalha na plimplim.com shoes, muito menos estou na Austrália (por enquanto, mas vai ser canadá)
valeu.
E você acha que esse foi meu primeiro empreo? Ou que a Globo.com era diferente do seu cenario em outubro do ano passado? O lugar ideal não existe, as pessoas devem lutar para mudar o cenário, esse é meu ponto.
Interessante, mas você poderia dar um exemplo de uma abstração não possível em Java ?
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.
Construção de instanciação paramétrica? Como assim ?
NewSpeak ?? Alguma coisa haver com 1984 ? Exemplos ?
Só uma perunta ra fechar, quantos % das suas classes eram Spring beans?Tenho de ver os fontes lá na fábrica pra te dizer, esse projeto não é nosso e nem está no cvs da fábrica.
O lugar ideal não existe, as pessoas devem lutar para mudar o cenário, esse é meu ponto.Concordo, mas não dá pra lutar sempre, temos de esperar pela hora certa.
NewSpeak ?? Alguma coisa haver com 1984 ? Exemplos ?Também fiquei curioso.
Qual linguagem tirando a exótica já citada oferece isso?
Suponho que linguagens funcionais ainda mais “exóticas” não contem. O sistema de módulos do Standard ML é assim. Se não me engano ADA possui um sistema de módulos paramétricos, só não sei bem como isso funciona no caso da parte OO da linguagem.
Alias, não entendi uma coisa: imaginando que instanciação de módulos com parâmetros seja algo como declarar as dependências de um módulo no corpo do código e e runtime obtêr esta dependências isso é Depency Injection, só que feito pelo runtime da linguagem ao inves de um container opcional, não? Sefor (não estou dizendo que seja)não vejo tana vantagem, injeção pode não ser a melhor escolha e poder optar por um outro outro é melhor. e eu quiser um modelo que tenha DI fácil eu poso desenvolver para um container específico.Eu concordo, entretanto, que os containers DI tendem a produzir configuracões bem extensas.
Módulos instanciaveis não se restringe apenas a DI da mesma maneira que generics (generics de verdade, assim como no C#) não se restringe apenas a collections. Quanto aos problemas de configuração, sistemas enormes provavelmente terão um problema semelhante quanto ao tamanho da cola com ambas as técnicas.
DI é uma necessidade quando não é possivel abstrair sobre tipos, simples assim.
Interessante, mas você poderia dar um exemplo de uma abstração não possível em Java ?
Não é possivel abstrair sobre os supertipos de uma classe. Não é possivel construir código realmente paramétrico, já que generics não permite qualquer operação sobre os parâmetros.
Construção de instanciação paramétrica? Como assim ?
Instanciar objetos baseado nos parâmetros do tipo.
class Foo<T> {
void bla() { T t = new T(); }
}
Esse foi um exemplo simples, mas com metaobjects de verdade é possivel ir bem além disso.
Procura pelas publicações recentes do Gilad Bracha.
Tá, mas falando de DI (que é o tema aqui).
Ok, então o problema não é específico de Java (ou C# ou C++ ou demais linguagens na linha de clonagem) e sim de todo um grupo extenso de possivelmente inclui Lisp, Smalltalk e Scala, certo? Se eu estiver certo comentaria que haver uma solução melor é ótimo mas não faz necessariamente da atual uma coisa ruim. Não é porque uma coisa é melhor que a outra é ruim.
Também não dá para esquecer do aumento de complexidade, Louds…
Você já viu alguns programas em C++ onde o sujeito faz o seguinte?
(Adaptando para sintaxe java-like)
class Foo<T> extends T {
public void bla() { T.doBlah(); }
}
Código genérico é complexo. Difícil de manter, difícil de debugar.
E não estou falando só do C++.
É difícil gerenciar tanta abstração e, embora em muitos casos as soluções sejam realmente elegantes, não adianta você ter um time em que o menos capacitado deva ter pelo menos uns 6 ou 8 anos de experiência.
Só para acrescentar, o Spring instrumenta o código à partir da cglib que é muito mais rápido que reflexão. Alguns preocupados com performance, chegaram a compará-lo com o Guice do Google e em sua nova versão, 2.5 , segundo a documentação oficial, está 200% mais rápido que seu concorrente.
Há muitas análises, bastaria uma googlada - http://www.javalobby.org/articles/guice-vs-spring.
Pesssoalmente, em meus projetos (faço uso extensivo do Spring), nunca senti gargalos de performance, pelo contrário.
[]´s
Kenobi.
Também não dá para esquecer do aumento de complexidade, Louds…Você já viu alguns programas em C++ onde o sujeito faz o seguinte?
(Adaptando para sintaxe java-like)
class Foo<T> extends T { public void bla() { T.doBlah(); } }Código genérico é complexo. Difícil de manter, difícil de debugar.
E não estou falando só do C++.É difícil gerenciar tanta abstração e, embora em muitos casos as soluções sejam realmente elegantes, não adianta você ter um time em que o menos capacitado deva ter pelo menos uns 6 ou 8 anos de experiência.
Evita muito trabalho de reflexão, por exemplo para construir engines. Costumo muito usar generics para criar camadas versáteis, escrevendo uma única vez.
Módulos instanciaveis não se restringe apenas a DI da mesma maneira que generics (generics de verdade, assim como no C#) não se restringe apenas a collections. Quanto aos problemas de configuração, sistemas enormes provavelmente terão um problema semelhante quanto ao tamanho da cola com ambas as técnicas.DI é uma necessidade quando não é possivel abstrair sobre tipos, simples assim.
Tá, mas falando de DI (que é o tema aqui).
Ok, então o problema não é específico de Java (ou C# ou C++ ou demais linguagens na linha de clonagem) e sim de todo um grupo extenso de possivelmente inclui Lisp, Smalltalk e Scala, certo? Se eu estiver certo comentaria que haver uma solução melor é ótimo mas não faz necessariamente da atual uma coisa ruim. Não é porque uma coisa é melhor que a outra é ruim.
Com Smalltalk é possivel criar algo bem próximo a módulos instanciaveis, isso se deve ao fato de ser uma linguagem baseada em troca de mensagens. Scala permite trait types e higher order parametric polymorphism, precisaria pensar em um bom exemplo, mas com Scala é possivel ter todos beneficios de DI sem ter um framework. Uma boa utilidade disso, por exemplo, é quando vc quer testar um tipo e precisa instanciá-lo com mocks ou stubs como dependencias. Usando um framework de DI esse processo é meio chato, se não precisa de DI, fica natural.
Não entendi, java também é baseada em troca de mensagens.
Scala permite trait types e higher order parametric polymorphism, precisaria pensar em um bom exemplo, mas com Scala é possivel ter todos beneficios de DI sem ter um framework. Uma boa utilidade disso, por exemplo, é quando vc quer testar um tipo e precisa instanciá-lo com mocks ou stubs como dependencias. Usando um framework de DI esse processo é meio chato, se não precisa de DI, fica natural.
Interessante, tem alguma referência? A única cisa relevate que achei no Google é meio contra isso:
Eu tenho impressão que você está jogando o bebê com a água suja mas devo estar errado.
O meu atual projeto usa DI e os seguintes pontos foram considerados:
No caso de decidir pelo spring:
eu gosto de IoC/DI e sempre que possível, utilizo, ainda mais que geralmente meus modelos de domínio são anêmicos (ou seja: não existe entidades/domínicos ricos)
motivos que os utilizo
e assim por diante