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.
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.[/quote]
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?
[quote=ViniGodoy]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.[/quote]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.
[quote=pcalcado]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.[/quote]“Geralmente” uma vez? OK, Spring então é mais rápido que java puro e simples? Não há reclamações da performance do Spring?
[quote=pcalcado]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.[/quote]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.
Quanto aos benefícios onde foi que discordei shoes?
[quote=ViniGodoy]Aliás, não é sobre isso que tenho falado desde o início? Que a gente tem é que pesar os benefícios/desvantagens?[/quote]Perdão, achei que vc estava só questionando. Estamos de acordo.
[quote=agodinhost]“Geralmente” uma vez? OK, Spring então é mais rápido que java puro e simples? Não há reclamações da performance do Spring?
[/quote]
Ahm? De onde voceê inferiu isso? Você instanciaria um componente mais de uma vez? para quê? Componentes com estado?
[quote=agodinhost]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.
[/quote]
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.
[quote=pcalcado]Ahm? De onde voceê inferiu isso? Você instanciaria um componente mais de uma vez? para quê? Componentes com estado?[/quote]Reinicialização de server por exemplo, clusters, farms, coisas assim.
[quote=pcalcado]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.[/quote]E vc fez isso tudo do dia pra noite?
[quote=pcalcado]Quantas vezes você reinicia seu servidor por semana?[/quote]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.
[quote=pcalcado]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.[/quote]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.
[quote=agodinhost]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.
[/quote]
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”.
[quote=pcalcado]Eu perguntei mais or curiosidade.[/quote]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.
[quote=pcalcado]Spring? Eu não estava faando de Spring, estava falando de testes, que foi sobre o que você falou “não ter orçamento”.[/quote]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?
[quote=agodinhost]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.[/quote]
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 ?
[quote=louds]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.
[/quote]
Construção de instanciação paramétrica? Como assim ?
NewSpeak ?? Alguma coisa haver com 1984 ? Exemplos ?
[quote=pcalcado]Só uma perunta ra fechar, quantos % das suas classes eram Spring beans?[/quote]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.
[quote=pcalcado]O lugar ideal não existe, as pessoas devem lutar para mudar o cenário, esse é meu ponto.[/quote]Concordo, mas não dá pra lutar sempre, temos de esperar pela hora certa.
Qual linguagem tirando a exótica já citada oferece isso?
[/quote]
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.
[quote=pcalcado]
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.[/quote]
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 ?
[/quote]
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 ?
[/quote]
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.
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.
