Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
O Portal javafree.org inicia mais uma promoção para os usuários do fórum. Quem publicar mais posts válidos (perguntas ou respostas) entre 16/4 a 13/7 levará para casa um iPad 2 de 16GB!
Eu tenho estudado (e apenas estudado) IoC já faz um tempo, e desde que iniciei os estudos naquela tradução do Ronald a seguinte questão me meio na cabeça:
Cadê a Simplicidade? :D (Dalton, Marcos e Ronald... devagar com as pedras :P)
Parece que IoC virou moda e tah todo mundo querendo usar simplesmente para dizer: "eu uso IoC".
Vou usar como alvo o Marcos (Jack) :D e o nosso projeto OpenNuke.
Bom, o Marcos implementou IoC para pegar, entre outras coisas, cada DAO que foi criado para o Hibernate. Visando uma futura independência de persistência. Criou uma arquitetura perfeita!
Porém o XML de configuração dos beans para o IoC do Spring ficou tão grande e tão ilegível que fica impossível uma pessoa que não conheça o Spring conseguir debugar aquilo, quanto mais modificar alguma coisa.
Por ser um projeto livre eu considero aceitável a solução, mas dificilmente usaria toda essa arquitetura simplesmente para prover independência de implementação.
Eu não vejo nada de mal nisso:
Ou, se quer realmente brincar com padrões, usar um Factory para criar a classe.
É claro, quando eu precisar usar uma outra implementação para a minha interface eu estou fudido (nem tanto). Mas até isso acontecer, se acontecer, eu prefiro escrever assim do que criar um XML ou uma outra classe de configuração de IoC gigante que vai complicar ainda mais a aplicação, que deveria ser simples.
Este tópico parece brincadeira, mas é o que muita gente está fazendo.
Cadê a Simplicidade? :D (Dalton, Marcos e Ronald... devagar com as pedras :P)
Vou jogar apenas nos telhados de vidro.
vfpamp:
Parece que IoC virou moda e tah todo mundo querendo usar simplesmente para dizer: "eu uso IoC".
A mesma coisa pra 'eu uso XP'. Pra maioria dos ditos 'adeptos do XP', isso é só uma desculpa pra não escrever documentação e fazer o sistema nas coxas. Quem não conhece, não faz direito e não vê os benefícios.
vfpamp:
Bom, o Marcos implementou IoC para pegar, entre outras coisas, cada DAO que foi criado para o Hibernate. Visando uma futura independência de persistência. Criou uma arquitetura perfeita!
Bem, no JavaBB, a gente usa o Spring pra conectar as camadas. Assim, a classe Action não precisa dar 'new' nas classes de transação, e estas nas classes de DAO. Configurar tudo por IoC dá ainda a vantagem de configurar serviços, como o controle transacional, sem adicionar uma única linha de código sobre isto nas classes de negócio. AOP poderia ser usada também (na verdade, isto é uma forma simples de AOP), mas nossas necessidades não requerem a complexidade de um AspectJ ou AspectWerkz. (e na minha opinião, ninguém realmente precisa disso)
vfpamp:
Porém o XML de configuração dos beans para o IoC do Spring ficou tão grande e tão ilegível que fica impossível uma pessoa que não conheça o Spring conseguir debugar aquilo, quanto mais modificar alguma coisa.
Bom, a configuração pode ficar bem mais simples com features como autowire e autoproxy do Spring.
vfpamp:
Por ser um projeto livre eu considero aceitável a solução, mas dificilmente usaria toda essa arquitetura simplesmente para prover independência de implementação.
Como eu já disse, independência de implementação é apenas uma vantagem. E nem é da Dependency Injection (DI, chamada genericamente e erroneamente de IoC), mas sim da programação por interfaces.
vfpamp:
Eu não vejo nada de mal nisso:
Não faz mal se isso é uma ArrayList que é usada localmente dentro de uma classe. Já se isso for uma classe de uma família de classes (como DAOs, por exemplo), que deve ser trocada em conjunto, fudeu. Além disso, isso dificulta o TDD (se você conhece XP, sabe do que eu estou falando, não é?), pois é difícil substituir as implementações por stubs de teste.
vfpamp:
Ou, se quer realmente brincar com padrões, usar um Factory para criar a classe.
A gente não brinca com padrões, a gente os usa por necessidade.
vfpamp:
É claro, quando eu precisar usar uma outra implementação para a minha interface eu estou fudido (nem tanto).
Ah, está sim!
vfpamp:
Mas até isso acontecer, se acontecer, eu prefiro escrever assim do que criar um XML ou uma outra classe de configuração de IoC gigante que vai complicar ainda mais a aplicação, que deveria ser simples.
Tá, então implementa um sistema com controle transacional, que possa ser testado com jUnit, e que possa usar DAOs Hibernate ou JDBC (Hibernate pode não ser permitido em alguns provedores, por usar manipulação de bytecode), sem recompilação de código, e vamos comparar as soluções pra ver qual a mais simples.
E por favor, não me venha com argumentos absurdos, já estou cansando de ficar explicando de novo, e de novo, coisas que eu sei que você já sabe.
Tetsuo
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Polêmica é legal! :D Faz agente pensar um monte de coisa :D
ronaldtm:
vfpamp:
Parece que IoC virou moda e tah todo mundo querendo usar simplesmente para dizer: "eu uso IoC".
A mesma coisa pra 'eu uso XP'. Pra maioria dos ditos 'adeptos do XP', isso é só uma desculpa pra não escrever documentação e fazer o sistema nas coxas. Quem não conhece, não faz direito e não vê os benefícios.
De acordo!
ronaldtm:
vfpamp:
Porém o XML de configuração dos beans para o IoC do Spring ficou tão grande e tão ilegível que fica impossível uma pessoa que não conheça o Spring conseguir debugar aquilo, quanto mais modificar alguma coisa.
Bom, a configuração pode ficar bem mais simples com features como autowire e autoproxy do Spring.
Detesto ter duas formas de resolver as coisas! :D Marcos, tah aih? :D Daria para usar isso? :D
ronaldtm:
vfpamp:
Por ser um projeto livre eu considero aceitável a solução, mas dificilmente usaria toda essa arquitetura simplesmente para prover independência de implementação.
Como eu já disse, independência de implementação é apenas uma vantagem. E nem é da Dependency Injection (DI, chamada genericamente e erroneamente de IoC), mas sim da programação por interfaces.
Ok, então para que adicionar IoC se há meios mais simples para fazer? :D
ronaldtm:
vfpamp:
Eu não vejo nada de mal nisso:
Não faz mal se isso é uma ArrayList que é usada localmente dentro de uma classe. Já se isso for uma classe de uma família de classes (como DAOs, por exemplo), que deve ser trocada em conjunto, f***. Além disso, isso dificulta o TDD (se você conhece XP, sabe do que eu estou falando, não é?), pois é difícil substituir as implementações por stubs de teste.
AbstractFactory?
TDD - Test Driven Development (Sem olhar, hein!) :D Arquivos de configuração não são patentes do Spring :D
ronaldtm:
vfpamp:
Ou, se quer realmente brincar com padrões, usar um Factory para criar a classe.
A gente não brinca com padrões, a gente os usa por necessidade.
Pelo menos os que sabem o que é YAGNI neh? :D
ronaldtm:
vfpamp:
É claro, quando eu precisar usar uma outra implementação para a minha interface eu estou fudido (nem tanto).
Ah, está sim!
Programação por interfaces... não to não :D
Sabia que existe replaceAll(), o Eclipse é bom nisso? :D heheheh xunxo mas é o mais simples....
Agora, se precisar usar as duas implementações ao mesmo tempo, aí você para e repensa como fazer. Até lá KISS!
ronaldtm:
vfpamp:
Mas até isso acontecer, se acontecer, eu prefiro escrever assim do que criar um XML ou uma outra classe de configuração de IoC gigante que vai complicar ainda mais a aplicação, que deveria ser simples.
Tá, então implementa um sistema com controle transacional, que possa ser testado com jUnit, e que possa usar DAOs Hibernate ou JDBC (Hibernate pode não ser permitido em alguns provedores, por usar manipulação de bytecode), sem recompilação de código, e vamos comparar as soluções pra ver qual a mais simples.
Bom, o Baba tah implementado com abstração de prevalência e persistência em AbstractFactory. Se não se importares em olhar lá. :D Os testes também não existem, mas eu estou começando a fazer.
Assim que me restar um tempinho eu vou colocar o Hibernate nele. [/quote]
ronaldtm:
E por favor, não me venha com argumentos absurdos, já estou cansando de ficar explicando de novo, e de novo, coisas que eu sei que você já sabe.
O que é um argumento absurdo, que IoC é uma merda? :D
PS: Sem contar que o XML não é compilável, podendo causar erros em várias partes da aplicação. Mais uma fonte de erros.
_________________
Vitor Pamplona http://vitorpamplona.com @vitorpamplona
Impecílios de se adicionar tecnologias em grandes sistemas e grandes equipes: - Toma-se tempo de alguém para dedicir e aprender a mexer no framework, claro, ninguém decide usar um um cara desses de uma hora para outra. - Leva-se de seis meses a um ano para o domínio completo da tecnologia. Isso, se for colocado em produção. Testando o fluxo do cliente. - O cara que pesquisou a tecnologia e domina ela será consultado de tempos em tempos. Erros, inconsistências, má configuração são as principais fontes. - Toda a equipe que trabalha na camada que usa a tecnologia em questão tem que DOMINAR a tecnologia. E, francamente, já temos siglas e conceitos demais para dominar. - Se você tem mais projetos para a mesma equipe e nenhum deles utiliza a tecnologia em questão, a equipe desaprenderá muito rápido, além de ficar desatualizada em relação a tecnologia. - A tecnologia envolvida se torna mais uma fonte de erros em produção. - Os implantadores e os atendentes terão que conhecer os documentos de configuração em XML do framework de IoC, em alguns casos, isso não é uma tarefa fácil. - Depois de muito se debater em criar tudo isso seu software cairá em desuso.
Enquanto isso: - Constrói uma Factory e cria um arquivinho simples de propriedades. Gera um manual de 2 páginas no máximo sobre o arquivo e manda pra todo mundo ler! _________________
Vitor Pamplona http://vitorpamplona.com @vitorpamplona
Polêmica é legal! :D Faz agente pensar um monte de coisa :D
Polêmica demais faz a gente se perder num mar de opiniões, perdendo o foco no assunto principal.
vfpamp:
Detesto ter duas formas de resolver as coisas! :D Marcos, tah aih? :D Daria para usar isso? :D
Mais de uma forma permite o uso da melhor pra cada situação. Você escolheria ter um esquema simples, mas menos flexível, ou flexível, mas complexo? Muitas vezes não é possível obter as duas simultaneamente, então são oferecidas as duas formas. 'O que é simples deve ser simples, o que é complexo deve ser possível.'
vfpamp:
Ok, então para que adicionar IoC se há meios mais simples para fazer? :D
Depende. Talvez a complexidade de se usar um framework IoC seja menor do que a soma da complexidade das soluções individuais de cada problema resolvido pela IoC.
vfpamp:
ronaldtm:
vfpamp:
Eu não vejo nada de mal nisso:
Não faz mal se isso é uma ArrayList que é usada localmente dentro de uma classe. Já se isso for uma classe de uma família de classes (como DAOs, por exemplo), que deve ser trocada em conjunto, f***. Além disso, isso dificulta o TDD (se você conhece XP, sabe do que eu estou falando, não é?), pois é difícil substituir as implementações por stubs de teste.
AbstractFactory?
Desculpe, eu não encontrei a fábrica abstrata no seu 'new MinhaClasseOverPower();'.
Ah, sim, esqueci. Daí, você vai brincar com padrões e adicionar a fábrica.
vfpamp:
ronaldtm:
vfpamp:
É claro, quando eu precisar usar uma outra implementação para a minha interface eu estou fudido (nem tanto).
Ah, está sim!
Programação por interfaces... não to não :D
Se você colocar os 'new' dentro de cada classe, como você disse acima que não achava mal nenhum, tá fudido sim!
vfpamp:
Sabia que existe replaceAll(), o Eclipse é bom nisso? :D heheheh xunxo mas é o mais simples....
Não confio em 'Replace All'. Por experiência própria, a medida que o sistema vai crescendo, fica mais difícil fazer um regex que substitua só nos lugares corretos.
vfpamp:
Bom, o Baba tah implementado com abstração de prevalência e persistência em AbstractFactory. Se não se importares em olhar lá. :D Os testes também não existem, mas eu estou começando a fazer.
Assim que me restar um tempinho eu vou colocar o Hibernate nele.
E ele tem controle transacional? Aliás, ele precisa de controle transacional? Que eu me lembre, ele era uma aplicação Swing. Ele tem uma parte servidor também? (puro desconhecimento, sorry).
Como eu já disse, frameworks afetam a arquitetura como um todo. Pode ser pra bem, pra mal, ou apenas uma opção de filosofia. O Spring daria um direcionamento à componentização e desacoplamento. Não sei como está a implementação do Baba, mas você tem a noção exata das dependências de cada classe? DI (vulgo IoC) permite isso, além de reduzir o custo da programação por interfaces (acredite, tem um custo, que pode se tornar bem alto) a quase zero.
vfpamp:
ronaldtm:
E por favor, não me venha com argumentos absurdos, já estou cansando de ficar explicando de novo, e de novo, coisas que eu sei que você já sabe.
O que é um argumento absurdo, que IoC é uma m***? :D
Não, mas tem vezes que você levanta mais polêmicas com 'e se's, desviando do assunto.
vfpamp:
PS: Sem contar que o XML não é compilável, podendo causar erros em várias partes da aplicação. Mais uma fonte de erros.
Isso é verdade. Ainda bem que a configuração no Spring pode ser bem simples, além de que podemos 'ligar' um verificador de dependências, alterando um simples atributo no XML, que se assegura de que todas as dependências estão sendo satisfeitas. Além disso, é possível também configurar o Spring programaticamente, pois seu mecanismo de configuração é bem flexível.
Tetsuo
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Impecílios de se adicionar tecnologias em grandes sistemas e grandes equipes: - Toma-se tempo de alguém para dedicir e aprender a mexer no framework, claro, ninguém decide usar um um cara desses de uma hora para outra. - Leva-se de seis meses a um ano para o domínio completo da tecnologia. Isso, se for colocado em produção. Testando o fluxo do cliente. - O cara que pesquisou a tecnologia e domina ela será consultado de tempos em tempos. Erros, inconsistências, má configuração são as principais fontes. - Toda a equipe que trabalha na camada que usa a tecnologia em questão tem que DOMINAR a tecnologia. E, francamente, já temos siglas e conceitos demais para dominar. - Se você tem mais projetos para a mesma equipe e nenhum deles utiliza a tecnologia em questão, a equipe desaprenderá muito rápido, além de ficar desatualizada em relação a tecnologia. - A tecnologia envolvida se torna mais uma fonte de erros em produção. - Os implantadores e os atendentes terão que conhecer os documentos de configuração em XML do framework de IoC, em alguns casos, isso não é uma tarefa fácil. - Depois de muito se debater em criar tudo isso seu software cairá em desuso.
Certo, então vamos jogar todos esses frameworks prontos fora e voltar a implementar nossos próprios frameworks de MVC e persistência! (comentário sarcástico, ignore)
Concordo, claro que o foco não deve ser na tecnologia, mas sim no problema a ser resolvido. Mas eu acho que alternativas devem ser sempre consideradas e estudadas, pois senão ficamos estagnados, perdidos das inovações e novas idéias que possam realmente melhorar a qualidade dos nossos softwares.
vfpamp:
Enquanto isso: - Constrói uma Factory e cria um arquivinho simples de propriedades. Gera um manual de 2 páginas no máximo sobre o arquivo e manda pra todo mundo ler!
Aqui um exemplo de argumento absurdo.
Tetsuo
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Já que o o Ronald já jogou todas as pedras no Vitor agora eu vou falar um pouquinho...
Eu tambem acho que a utilização de frameworks como o Primavera, deixam um projeto um pouco sujo. Não há nada que ele faça que não seja resolvido elegantemente com um Factory Method um Abstract Factory. A parte transacional é controlada pelo WW (ou pelo menos era, através de Interceptor) ele apenas carregas as DAOs, e outras necessidades de execução nas Actions e camadas envolvidas, porém a quantidade de XML gerada me faz pensar: -Em que isso vale realmente a pena? Pra mim o projeto fica mais dificil de ser debugado, uma vez que para isso é preciso conhecer detalhes da implementação de um framework para saber exatamente seu comportamento. Em outras palavras, é fácil quando o StackTrace te mostra uma erro em uma classe sua, você vai no código e faz as alterações necessárias, agora quando o erro é mostrado em uma classe do framework a coisa fica mais complicada.
Não sou totalmente contra a utilização de frameworks, mais eu acho que tudo deve ser dosado adequadamente, assim como disse o Vitor disse, não é porque uma coisa tá na moda que deve ser usada em todo e qualquer lugar. Pra mim, a quantidade de XML que precisa ser gerada para o Spring (não sei se existe xDoclet pra isso) acaba saindo 6 por meia dúzia com relação a uma programação usando outras patterns.
Bom pessoal, essa é minha opinião, não estou pedindo pra ninguem concordar comigo, mais se quiserem me mestrar que eu estou errado, por favor, não exitem.
Enquanto isso: - Constrói uma Factory e cria um arquivinho simples de propriedades. Gera um manual de 2 páginas no máximo sobre o arquivo e manda pra todo mundo ler!
Enquanto isso: - Constrói uma Factory e cria um arquivinho simples de propriedades. Gera um manual de 2 páginas no máximo sobre o arquivo e manda pra todo mundo ler!
Aqui um exemplo de argumento absurdo.
Tetsuo
Porque Ronald?
Também pergunto isso...
Não to dizendo que é para jogar fora os frameworks, mas não me venha dizer que IoC é simples... _________________
Vitor Pamplona http://vitorpamplona.com @vitorpamplona
Detesto ter duas formas de resolver as coisas! Marcos, tah aih? Daria para usar isso?
Mais de uma forma permite o uso da melhor pra cada situação. Você escolheria ter um esquema simples, mas menos flexível, ou flexível, mas complexo? Muitas vezes não é possível obter as duas simultaneamente, então são oferecidas as duas formas. 'O que é simples deve ser simples, o que é complexo deve ser possível.'
Entre simplicidade e flexibilidade eu prefiro simplicidade!
ronaldtm:
Depende. Talvez a complexidade de se usar um framework IoC seja menor do que a soma da complexidade das soluções individuais de cada problema resolvido pela IoC.
Será? Acho muito difícil.
ronaldtm:
Desculpe, eu não encontrei a fábrica abstrata no seu 'new MinhaClasseOverPower();'.
Ah, sim, esqueci. Daí, você vai brincar com padrões e adicionar a fábrica.
Bom, se você ACHAR que vai precisar criar uma independência é muito mais simples criar um Factory do que importar um Framework completo de IoC cheio de outras coisas que nunca vai passar pela sua cabeça usar
ronaldtm:
Se você colocar os 'new' dentro de cada classe, como você disse acima que não achava mal nenhum, tá fudido sim!
Meu... Já viu quanto tempo isso leva? 1 hora no máximo para alterar em um sistema grande. Isso se encaixa em qualquer orçamento.
ronaldtm:
E ele tem controle transacional? Aliás, ele precisa de controle transacional? Que eu me lembre, ele era uma aplicação Swing. Ele tem uma parte servidor também? (puro desconhecimento, sorry).
Tem as transactions do Prevayler que vão virar Transações no Hibernate. E você não disse que precisava ter um servidor.
ronaldtm:
Como eu já disse, frameworks afetam a arquitetura como um todo. Pode ser pra bem, pra mal, ou apenas uma opção de filosofia. O Spring daria um direcionamento à componentização e desacoplamento. Não sei como está a implementação do Baba, mas você tem a noção exata das dependências de cada classe? DI (vulgo IoC) permite isso, além de reduzir o custo da programação por interfaces (acredite, tem um custo, que pode se tornar bem alto) a quase zero.
Eu sei. Pra não dizer que tudo é dependente, o que separa é uma linha no arquivo de properties que identifica qual modelo de persistência será utilizado. Isso já é mais que o suficiente para prover essa independência.
_________________
Vitor Pamplona http://vitorpamplona.com @vitorpamplona
Já que o o Ronald já jogou todas as pedras no Vitor agora eu vou falar um pouquinho...
Eu tambem acho que a utilização de frameworks como o Primavera, deixam um projeto um pouco sujo. Não há nada que ele faça que não seja resolvido elegantemente com um Factory Method um Abstract Factory. A parte transacional é controlada pelo WW (ou pelo menos era, através de Interceptor) ele apenas carregas as DAOs, e outras necessidades de execução nas Actions e camadas envolvidas, porém a quantidade de XML gerada me faz pensar: -Em que isso vale realmente a pena? Pra mim o projeto fica mais dificil de ser debugado, uma vez que para isso é preciso conhecer detalhes da implementação de um framework para saber exatamente seu comportamento. Em outras palavras, é fácil quando o StackTrace te mostra uma erro em uma classe sua, você vai no código e faz as alterações necessárias, agora quando o erro é mostrado em uma classe do framework a coisa fica mais complicada.
Não sou totalmente contra a utilização de frameworks, mais eu acho que tudo deve ser dosado adequadamente, assim como disse o Vitor disse, não é porque uma coisa tá na moda que deve ser usada em todo e qualquer lugar. Pra mim, a quantidade de XML que precisa ser gerada para o Spring (não sei se existe xDoclet pra isso) acaba saindo 6 por meia dúzia com relação a uma programação usando outras patterns.
Bom pessoal, essa é minha opinião, não estou pedindo pra ninguem concordar comigo, mais se quiserem me mestrar que eu estou errado, por favor, não exitem.
[]'s
Bom, vou dar a minha opiniao, (humilde, simples e talvez insignificante).... Concordo com o que o Volnei disse ai em cima. Não sou contra a utlização de Frameworks como o Spring, mas como ele mesmo disse, a do sistema acaba se tornando "inacessivel" para novos desenvolvedores... Talvez soh para novos? Não... para desenvolvedores com um pouco menos de conhecimento tb....
Querem um exemplo real? Olhem para mim, simplesmente depois de 47239847230984723 arquivos xml entrarem em vigor no javaBB definindo as injecoes e o resto de grandes mudancas, eu simplesmente me perdi, e com tudo que tava empolgado e tenha tentado, nao consegui acompanhar o projeto....
E olhem que eu tentei... Foi um balde de agua fria... ehaehahe
_________________
Lucas Teixeira .·. lucas@ltvm.net
Bom, vou dar a minha opiniao, (humilde, simples e talvez insignificante).... Concordo com o que o Volnei disse ai em cima. Não sou contra a utlização de Frameworks como o Spring, mas como ele mesmo disse, a do sistema acaba se tornando "inacessivel" para novos desenvolvedores... Talvez soh para novos? Não... para desenvolvedores com um pouco menos de conhecimento tb....
Querem um exemplo real? Olhem para mim, simplesmente depois de 47239847230984723 arquivos xml entrarem em vigor no javaBB definindo as injecoes e o resto de grandes mudancas, eu simplesmente me perdi, e com tudo que tava empolgado e tenha tentado, nao consegui acompanhar o projeto....
E olhem que eu tentei... Foi um balde de agua fria... ehaehahe
Nada como um exemplo prático!
E onde foi a simplicidade? E oque aumentou em flexibilidade no JavaBB? Tudo que está sendo feito com os 47239847230984723 de arquivos XML de pelo menos 2000000 de linhas poderia ser resolvido com o method factory, não?
_________________
::volnei::
Olhem que interessante, está um pouco fora do contexto (nao eh o applicationContext nao... ) mas alguem conhece o VRaptor? É um framework tal como o WW, alias, beeeeeem parecido com ele....
olhem o que ele diz sobre a implementacao de IoC:
Quote:
Quoting Fowlers article, when he is talking how to wire up your services and components:
Fowler:
"I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism. Modern languages can easily compile small assemblers that can be used to assemble plugins for larger systems. If compilation is a pain, then there are scripting languages that can work well also. It's often said that configuration files shouldn't use a programing language because they need to be edited by non-programmers. But how often is this the case? Do people really expect non-programmers to alter the transaction isolation levels of complex server-side application? Non-language configuration files work well only to the extent they are simple. If they become complex then it's time to think about using a proper programming language."
This is the reason why vraptor has chosen not to have something like webwork's component.xml and spring's application context.
Most of the time I see myself doing complex "xml coding" because one of my component's lifecycle is quite difficult to describe in a xml file. It is much more simple to do it in plain java code, making it easier to write and to read.
Giving a programming interface to register the components to be injected, it is easy for the developers to create its own configuration file, instead of trying to create a bizarre and general xml syntax that should handle all kind of lifecycles, init methods, factories, and so on.
_________________
Lucas Teixeira .·. lucas@ltvm.net
No artigo do Martin fala que o PicoContainer também não tem xml pq é muito complexo.
Nada mal... pelo menos alguém já pensou mais simples , mas mesmo assim, acho muita coisa para pouco benefício prático. Mas eu vou dar uma olhada mais afundo no vRaptor (que por sinal é brasileiro) e no Pico.
Bom, só para meter mais um pouquinho o "pau" no Vítor, pense que todo mapeamento de suas classes estão em um arquivo externo, nada de abrir o eclipse pra recompilar sua classe "factory", caso você faça uma nova implementação. Tudo bem, você poderia usar um XML como base de sua Factory correto? Sim, mas e porque não usar IoC ao invés desta gambiarra?
Você tomou como exemplo o OpenNuke (Marcos e seu xmlzão...), pena que nós não gravamos a batalha no MSN entre eu, o Ronald e o Marcos, tentando convencê-lo que o XML dele está enoooorme, e ficaria pouco manutenível na hora que um final user tentar modificar alguma coisa, tipo configuração do BD É, parece que agora estamos tendo progresso, uma vez que ele vai olhar daqui a uma semana aquele XML e dizer: -"Nossa, eu fiz isso?"
Marcos é brincadeira heim?
No bb estamos usando o autowire byName do Spring (Tks to Ronald), o que deixa ainda mais legal brincar de DI
Pessoas polêmicas acreditam que DI pode vir a atropelar o yagni, porém, quando você tem um padrão de projeto legal, sabe exatamente qual vai ser sua estrutura de classes, basta ir acrescentando componentes via DI na mesma, sem ter que passar pelo stress de encapsular o componente na lógica do teu projeto _________________
Sugestão de Livros
pense que todo mapeamento de suas classes estão em um arquivo externo, nada de abrir o eclipse pra recompilar sua classe "factory", caso você faça uma nova implementação. Tudo bem, você poderia usar um XML como base de sua Factory correto? Sim, mas e porque não usar IoC ao invés desta gambiarra?
Pelas razões citadas no 4 post? E ainda troca-se uma linha de um arquivo de properties para várias linhas de um bosta de XML.
Além do mais, acho que o Lucas ainda ta perdido. E olha que é o Lucas hein... não é qualquer coisa...
Olhem que interessante, está um pouco fora do contexto (nao eh o applicationContext nao... ) mas alguem conhece o VRaptor? É um framework tal como o WW, alias, beeeeeem parecido com ele....
olhem o que ele diz sobre a implementacao de IoC:
Quote:
Quoting Fowlers article, when he is talking how to wire up your services and components:
Fowler:
"I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism. Modern languages can easily compile small assemblers that can be used to assemble plugins for larger systems. If compilation is a pain, then there are scripting languages that can work well also. It's often said that configuration files shouldn't use a programing language because they need to be edited by non-programmers. But how often is this the case? Do people really expect non-programmers to alter the transaction isolation levels of complex server-side application? Non-language configuration files work well only to the extent they are simple. If they become complex then it's time to think about using a proper programming language."
This is the reason why vraptor has chosen not to have something like webwork's component.xml and spring's application context.
Most of the time I see myself doing complex "xml coding" because one of my component's lifecycle is quite difficult to describe in a xml file. It is much more simple to do it in plain java code, making it easier to write and to read.
Giving a programming interface to register the components to be injected, it is easy for the developers to create its own configuration file, instead of trying to create a bizarre and general xml syntax that should handle all kind of lifecycles, init methods, factories, and so on.
Argh! No thanks, não uso drogas _________________
Sugestão de Livros
Querem um exemplo real? Olhem para mim, simplesmente depois de 47239847230984723 arquivos xml entrarem em vigor no javaBB definindo as injecoes e o resto de grandes mudancas, eu simplesmente me perdi, e com tudo que tava empolgado e tenha tentado, nao consegui acompanhar o projeto....
E olhem que eu tentei... Foi um balde de agua fria... ehaehahe
Com a adição do Spring, foi acrescentado UM arquivo XML, que atualmente possui exatas 125 linhas (o xwork.xml tem 78. Isso porque eu estou passando a configuração do Hibernate pra dentro do Spring, antes disso ele tinha umas 50 linhas (quase cabia em uma tela), sendo que cada linha continha, basicamente, uma declaração de classe.
Excluindo os arquivos de mapeamento do Hibernate, o projeto todo tem 7 arquivos XML:
build.xml - Ant project.xml - Maven (tentativa, não utilizado atualmente) log4j.xml - Log4J hibernate.cfg.xml - Hibernate (configuração) xwork.xml - WebWork applicationContext.xml - Spring web.xml - Container web
Ah, sim, eu também adicionei um XML com as configurações de formatação de código do Eclipse, mas isso não entra na construção da aplicação.
A adição do Spring não adicionou tanta configuração assim ao projeto. Mas uma coisa que foi alterada foi a forma de se programar, pois agora temos os princípios de componentização a serem seguidos, ao invés de sair dando 'new' direto.
Talvez, o lucas tenha se perdido, porque, além de adicionarmos o Spring, também alteramos a estrutura de diretórios do projeto. Antes, a raiz do contexto web tava no raiz do projeto, o que facilitava a montagem do ambiente de desenvolvimento, mas deixava a estrutura do projeto confusa. Agora os diretórios de fontes estão separados e organizados, mas é preciso um passo extra pra rodar a aplicação, que é a construção com o Ant.
Tetsuo
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
OQUE ISSO TEM DE MELHOR DOQUE USAR UM FACTORY? QUAIS AS VANTAGENS? Até agora ninguem respondeu isso!
Acho que você não entendeu ainda muito bem o espírito da 'coisa'. Vamos tomar o exemplo do bb: O DI do Spring não está servindo apenas para como uma factory (mesmo se estivesse sendo, já seria um ganho enorme), mas também com a componentização do código, onde agora o princípio básico é, componentizar! Ao invés de termos um new ComponenteDataUtil(); dentro da nossa action, apenas temos um setter de uma Interface componente por ex(tudo bem, hoje nós não estamos usando interfaces nos componentes, mas esqueça isso), então você não precisa mais ligar a Action com a ComponenteDateUtil através de bytecode:
Ou seja:
Deixa que o spring faz isso pra vc :!:
Conseguiu entender melhor? Cya!
_________________
Sugestão de Livros
Bom, só para meter mais um pouquinho o "pau" no Vítor, pense que todo mapeamento de suas classes estão em um arquivo externo, nada de abrir o eclipse pra recompilar sua classe "factory", caso você faça uma nova implementação. Tudo bem, você poderia usar um XML como base de sua Factory correto? Sim, mas e porque não usar IoC ao invés desta gambiarra?
Você achar que o Factory é uma gambiarra ? Além disso nem todas as implementações do Factory necessitam ser recompiladas, e se precisar, é mais fácil para qualquer usuário compilar uma classe doque conhecer toda a estrutura de um framework para poder alterar um XML, seja ele do tamanho que for...
Bom, conhecer um framework, é o princípio básico para um profissional ser contrato em uma empresa _________________
Sugestão de Livros
Bom, só para meter mais um pouquinho o "pau" no Vítor, pense que todo mapeamento de suas classes estão em um arquivo externo, nada de abrir o eclipse pra recompilar sua classe "factory", caso você faça uma nova implementação. Tudo bem, você poderia usar um XML como base de sua Factory correto? Sim, mas e porque não usar IoC ao invés desta gambiarra?
Você achar que o Factory é uma gambiarra ? Além disso nem todas as implementações do Factory necessitam ser recompiladas, e se precisar, é mais fácil para qualquer usuário compilar uma classe doque conhecer toda a estrutura de um framework para poder alterar um XML, seja ele do tamanho que for...
Bom, conhecer um framework, é o princípio básico para um profissional ser contrato em uma empresa
Por um acaso os desenvolvedores do Spring são os donos da verdade? Não podem ser questinados? Acho que estamos em uma disussão aberta, pelo qual espero que você tenha lido antes de colocar esse "comentário".
Vamos perguntar para o Gavin se o Hibernate é bom!
Desculpa, mais sinceramente vocês não estão preocupados em responder as perguntas, mas sim e defender o framework.
E Junior, eu já li, ele funciona! E daí?
_________________
::volnei::
Enquanto isso: - Constrói uma Factory e cria um arquivinho simples de propriedades. Gera um manual de 2 páginas no máximo sobre o arquivo e manda pra todo mundo ler!
Como você mesmo disse, pra que ficar re-inventado a roda? Documentação já existe pronta, e se vc não quer usar todo o "poder" do spring, coloca o spring.jar no teu projeto e usa só o DI dele, e além disso, você não terá apenas uma pessoa para consultar, mas milhares de pessoas mundo a fora que já usam essa tecnologia _________________
Sugestão de Livros
O DI do Spring não está servindo apenas para como uma factory (mesmo se estivesse sendo, já seria um ganho enorme), mas também com a componentização do código, onde agora o princípio básico é, componentizar!
Claro, componentizar é maravilhoso exceto se você não precisa disso.
Conhecer frameworks só é bom para saber quando não usá-los .
Mas estamos discutindo IoC ou DI como quiserem não o Spring.
Quem conseguir responder a pergunta:
Quote:
Porque não construir uma Factory, um arquivinho simples de propriedades e gerar um manual de 1/2 página no máximo?
Enquanto isso: - Constrói uma Factory e cria um arquivinho simples de propriedades. Gera um manual de 2 páginas no máximo sobre o arquivo e manda pra todo mundo ler!
Como você mesmo disse, pra que ficar re-inventado a roda? Documentação já existe pronta, e se vc não quer usar todo o "poder" do spring, coloca o spring.jar no teu projeto e usa só o DI dele, e além disso, você não terá apenas uma pessoa para consultar, mas milhares de pessoas mundo a fora que já usam essa tecnologia
Reinventando a roda? Desde quando criar uma classe é reinventar a roda?
Por um acaso os desenvolvedores do Spring são os donos da verdade? Não podem ser questinados? Acho que estamos em uma disussão aberta, pelo qual espero que você tenha lido antes de colocar esse "comentário".
Vamos perguntar para o Gavin se o Hibernate é bom!
Desculpa, mais sinceramente vocês não estão preocupados em responder as perguntas, mas sim e defender o framework.
E Junior, eu já li, ele funciona! E daí?
Não cara, eu de maneira alguma estou tentando te convencer a usar Spring ou alguma outra coisa mas é que você está questinando a funcionalidade do framework, na bem da verdade, do conceito IoC, eu acho que se você já leu a documentação sobre Spring, não gosta da mesma, então não há o porque ficar discutindo com quem gosta, afinal, usar frameworks é como ter time de futebol, não se discute, e o que tenho visto você fazer, é só perguntar, perguntar, e perguntar, não comprovou que você usou e não gostou por isso, isso e aquilo.
Enquanto isso: - Constrói uma Factory e cria um arquivinho simples de propriedades. Gera um manual de 2 páginas no máximo sobre o arquivo e manda pra todo mundo ler!
Como você mesmo disse, pra que ficar re-inventado a roda? Documentação já existe pronta, e se vc não quer usar todo o "poder" do spring, coloca o spring.jar no teu projeto e usa só o DI dele, e além disso, você não terá apenas uma pessoa para consultar, mas milhares de pessoas mundo a fora que já usam essa tecnologia
Reinventando a roda? Desde quando criar uma classe é reinventar a roda?
E se eu quiser uma roda menor? .
Bom, e se eu quiser usar NetBeans, Visual Café ou JDeveloper? Bom, aí é com vc, afinal, graças a Alá, somos desenvolvedores LIVRES (Javeiros) e temos centenas de opções para desenvolver um bom software, vai do engenheiro definir o que é melhor para o projeto _________________
Sugestão de Livros
Não cara, eu de maneira alguma estou tentando te convencer a usar Spring ou alguma outra coisa mas é que você está questinando a funcionalidade do framework, na bem da verdade, do conceito IoC, eu acho que se você já leu a documentação sobre Spring, não gosta da mesma, então não há o porque ficar discutindo com quem gosta, afinal, usar frameworks é como ter time de futebol, não se discute, e o que tenho visto você fazer, é só perguntar, perguntar, e perguntar, não comprovou que você usou e não gostou por isso, isso e aquilo.
[]s
Não estou questionando a funcionalidade, como eu disse, ele funciona, mais sim a utilidade. Porque você precisa aprender uma tecnologia nova que não te trás benefícios? É isso, eu não vejo benefícios em usar o Spring. Se funciona, é o mínimo, o problema é que estou tentando fazer alguem (que gosta e utiliza) me disse, olha ele é melhor por isso e por aquilo, desde que não sejam recursos alcançados com um Factory um Singleton ou qualquer outro pattern simples.
_________________
::volnei::
Claro, componentizar é maravilhoso exceto se você não precisa disso.
Se você não precisa de alguma forma de componentização, então é porque o sistema é tão ridículo que não vale a pena ser discutido.
vfpamp:
Conhecer frameworks só é bom para saber quando não usá-los .
Bom, muito bom, então porque você está querendo criar um?
vfpamp:
Mas estamos discutindo IoC ou DI como quiserem não o Spring.
Você sequer sabe o que é IoC exatamente?
E eu estou usando o Spring como exemplo, porque é o que eu conheço melhor.
vfpamp:
Quem conseguir responder a pergunta:
Quote:
Porque não construir uma Factory, um arquivinho simples de propriedades e gerar um manual de 1/2 página no máximo?
Ganha um brinde!
Porque isso cobre apenas um caso de aplicação de um container leve, que é a criação dos objetos. Mas você desconsidera completamente a configuração, o ciclo de vida e o gerenciamento dos componentes.
Não estou dizendo 'não façam mais factories', mas sim, 'factories não resolvem todos os problemas necessários'. Digamos que o 'new' está para uma abstract factory assim como uma abstract factory está para um container DI.
Tetsuo
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Porque você precisa aprender uma tecnologia nova que não te trás benefícios? É isso, eu não vejo benefícios em usar o Spring. Se funciona, é o mínimo, o problema é que estou tentando fazer alguem (que gosta e utiliza) me disse, olha ele é melhor por isso e por aquilo, desde que não sejam recursos alcançados com um Factory um Singleton ou qualquer outro pattern simples.
Olha, ele é melhor por isso: - facilita a criação, configuração e montagem dos componentes - cuida do ciclo de vida de um componente, por exemplo, se ele vai ser um singleton ou não. - fonece uma forma simplificada de AOP - promove a componentização
e por aquilo: - se integra facilmente com qualquer outro framework - não é invasivo como EJBs - você pode usar apenas o que quiser - possui, além do container, uma biblioteca imensa de classes que seguem a filosofia do framework. Você não precisa reimplementar um gerenciador de transações, basta configurar um interceptor, já incluso no pacote, com uma das opções de gerenciadores (para JDBC, JTA, Hibernate, JDO), também inclusas. Em suma, pra muita coisa, você não precisa codificar uma linha sequer, basta configurar seus componentes de negócio com as classes já existentes. Pra outras, basta usar uma classe do pacote que fornece uma interface bem mais simples de usar que a original (javamail, por exemplo).
Depois eu vejo se lembro de mais alguma coisa
Tetsuo
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Parecem crianças que ganharam um brinquedo novo. Antes de existir o Spring já eram desenvolvidos boas aplicações Ronald e vão continuar sendo desenvolvidas sem ele.
Quer saber, vocês falam, enrolam e não respondem nada, dizer que é bom tudo bem, mais em que é melhor eu ainda não vi.
E Ronald, desde quando precisa de Spring para componentização?
_________________
::volnei::
Claro, componentizar é maravilhoso exceto se você não precisa disso.
Se você não precisa de alguma forma de componentização, então é porque o sistema é tão ridículo que não vale a pena ser discutido.
Poisé... pelo menos eu estou tentando deixar todos os projetos que eu participo ridiculamente SIMPLES! E aih, IoC é simples?
ronaldtm:
vfpamp:
Conhecer frameworks só é bom para saber quando não usá-los .
Bom, muito bom, então porque você está querendo criar um?
Tópico errado
ronaldtm:
vfpamp:
Mas estamos discutindo IoC ou DI como quiserem não o Spring.
Você sequer sabe o que é IoC exatamente?
E eu estou usando o Spring como exemplo, porque é o que eu conheço melhor.
Sim, quantos livros eu vou ter que ler para conhecer IoC? Cada vez isso fica mais complexo.
ronaldtm:
vfpamp:
Quem conseguir responder a pergunta:
Quote:
Porque não construir uma Factory, um arquivinho simples de propriedades e gerar um manual de 1/2 página no máximo?
Ganha um brinde!
Porque isso cobre apenas um caso de aplicação de um container leve, que é a criação dos objetos. Mas você desconsidera completamente a configuração, o ciclo de vida e o gerenciamento dos componentes.
Imagino que adicionando configurações o XML tende a crescer, não? Simplicidade?
Cliclo de vida o Java resolve sozinho GC , ou é pela lógica do programador, que normalmente já está ambientado com isso.
ronaldtm:
Não estou dizendo 'não façam mais factories', mas sim, 'factories não resolvem todos os problemas necessários'. Digamos que o 'new' está para uma abstract factory assim como uma abstract factory está para um container DI.
Exemplo prático, as DAOs do ON poderiam ser criadas com um Abstract Fatory, não precisam de gerenciamento, ciclo de vida ou configuração. Uso incorreto?
_________________
Vitor Pamplona http://vitorpamplona.com @vitorpamplona
- facilita a criação, configuração e montagem dos componentes
Tem algo mais fácil que new XX( "Teste do Vitor" ); ? :D
Quote:
- cuida do ciclo de vida de um componente, por exemplo, se ele vai ser um singleton ou não.
Isso é no XML certo? Prefiro implementar um Singleton, que, lembrando é só mais um método estático na classe.
Quote:
- fonece uma forma simplificada de AOP
E quem disse que eu preciso disso?
Quote:
- promove a componentização
Troque por força a componentização. Componentização aumenta os custos com gerencia do projeto.
Quote:
- se integra facilmente com qualquer outro framework
Preciso falar alguma coisa, quando estamos discutindo simplicidade?
Quote:
- não é invasivo como EJBs
...
Quote:
- você pode usar apenas o que quiser
Claro, depois de ler 5 livros e 10 tutoriais diferentes.
Quote:
- possui, além do container, uma biblioteca imensa de classes que seguem a filosofia do framework. Você não precisa reimplementar um gerenciador de transações, basta configurar um interceptor, já incluso no pacote, com uma das opções de gerenciadores (para JDBC, JTA, Hibernate, JDO), também inclusas. Em suma, pra muita coisa, você não precisa codificar uma linha sequer, basta configurar seus componentes de negócio com as classes já existentes. Pra outras, basta usar uma classe do pacote que fornece uma interface bem mais simples de usar que a original (javamail, por exemplo).
Biblioteca imensa de classes? Gerenciador de Transações? Algo assim?
O Pico Container também tem isso tudo? Lembrem-se, estamos discutindo IoC, não a bosta do Spring ::D
_________________
Vitor Pamplona http://vitorpamplona.com @vitorpamplona
Parecem crianças que ganharam um brinquedo novo. Antes de existir o Spring já eram desenvolvidos boas aplicações Ronald e vão continuar sendo desenvolvidas sem ele.
Sim, mas necessitavam de uma quantidade de trabalho bem maior.
volnei:
Quer saber, vocês falam, enrolam e não respondem nada, dizer que é bom tudo bem, mais em que é melhor eu ainda não vi.
Bom, eu respondi, se você não entendeu, não é problema meu.
volnei:
E Ronald, desde quando precisa de Spring para componentização?
Spring PROMOVE componentização.
Ah, não, cansei de vocês dois, chega. Vocês que parecem crianças, tampando os ouvidos e gritando 'não estou ouvindo, não estou ouvindo'. Fodam-se.
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
- facilita a criação, configuração e montagem dos componentes [/color:3e88ccdd39] Isso é oque mais foi discutido aqui, até um factory bem implementado facilita.
[color=blue:3e88ccdd39]- cuida do ciclo de vida de um componente, por exemplo, se ele vai ser um singleton ou não.[/color:3e88ccdd39] E qual a vantagem? Implementar um singleton reutilizável é a coisa mais simples que tem.
[color=blue:3e88ccdd39]- fonece uma forma simplificada de AOP [/color:3e88ccdd39] AOP nasceu antes do Spring, aliás, bem antes.
[color=blue:3e88ccdd39]- promove a componentização [/color:3e88ccdd39] Já disse, a componentização não depende o Spring.
[color=blue:3e88ccdd39]- se integra facilmente com qualquer outro framework [/color:3e88ccdd39] É o minimo, já pensou se não se integrasse?
[color=]- não é invasivo como EJBs Não posso falar sobre isso, nunca trabalhei com EJB.
- você pode usar apenas o que quiser[/color:3e88ccdd39] Eu já faço isso.
[color=]- possui, além do container, uma biblioteca imensa de classes que seguem a filosofia do framework. Você não precisa reimplementar um gerenciador de transações, basta configurar um interceptor, já incluso no pacote, com uma das opções de gerenciadores (para JDBC, JTA, Hibernate, JDO), também inclusas. Em suma, pra muita coisa, você não precisa codificar uma linha sequer, basta configurar seus componentes de negócio com as classes já existentes. Pra outras, basta usar uma classe do pacote que fornece uma interface bem mais simples de usar que a original (javamail, por exemplo). Agora sim! Isso realmente é um vantagem!!! _________________
::volnei::
vfpamp Offline
Posts: 6010
Se você não sabe o que é, leia:http://www.javafree.com.br/home/modules.php?name=Content&pa=showpage&pid=4
Eu tenho estudado (e apenas estudado) IoC já faz um tempo, e desde que iniciei os estudos naquela tradução do Ronald a seguinte questão me meio na cabeça:
Cadê a Simplicidade? :D (Dalton, Marcos e Ronald... devagar com as pedras :P)
Parece que IoC virou moda e tah todo mundo querendo usar simplesmente para dizer: "eu uso IoC".
Vou usar como alvo o Marcos (Jack) :D e o nosso projeto OpenNuke.
Bom, o Marcos implementou IoC para pegar, entre outras coisas, cada DAO que foi criado para o Hibernate. Visando uma futura independência de persistência. Criou uma arquitetura perfeita!
Porém o XML de configuração dos beans para o IoC do Spring ficou tão grande e tão ilegível que fica impossível uma pessoa que não conheça o Spring conseguir debugar aquilo, quanto mais modificar alguma coisa.
Por ser um projeto livre eu considero aceitável a solução, mas dificilmente usaria toda essa arquitetura simplesmente para prover independência de implementação.
Eu não vejo nada de mal nisso:
Ou, se quer realmente brincar com padrões, usar um Factory para criar a classe.
É claro, quando eu precisar usar uma outra implementação para a minha interface eu estou fudido (nem tanto). Mas até isso acontecer, se acontecer, eu prefiro escrever assim do que criar um XML ou uma outra classe de configuração de IoC gigante que vai complicar ainda mais a aplicação, que deveria ser simples.
Este tópico parece brincadeira, mas é o que muita gente está fazendo.
E não se esqueçam do YAGNI :D
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
ronaldtm Offline
Posts: 2299
(suspiro) Vitor e sua mania de criar polêmica...
Vou jogar apenas nos telhados de vidro.
A mesma coisa pra 'eu uso XP'. Pra maioria dos ditos 'adeptos do XP', isso é só uma desculpa pra não escrever documentação e fazer o sistema nas coxas. Quem não conhece, não faz direito e não vê os benefícios.
Bem, no JavaBB, a gente usa o Spring pra conectar as camadas. Assim, a classe Action não precisa dar 'new' nas classes de transação, e estas nas classes de DAO. Configurar tudo por IoC dá ainda a vantagem de configurar serviços, como o controle transacional, sem adicionar uma única linha de código sobre isto nas classes de negócio. AOP poderia ser usada também (na verdade, isto é uma forma simples de AOP), mas nossas necessidades não requerem a complexidade de um AspectJ ou AspectWerkz. (e na minha opinião, ninguém realmente precisa disso)
Bom, a configuração pode ficar bem mais simples com features como autowire e autoproxy do Spring.
Como eu já disse, independência de implementação é apenas uma vantagem. E nem é da Dependency Injection (DI, chamada genericamente e erroneamente de IoC), mas sim da programação por interfaces.
Não faz mal se isso é uma ArrayList que é usada localmente dentro de uma classe. Já se isso for uma classe de uma família de classes (como DAOs, por exemplo), que deve ser trocada em conjunto, fudeu. Além disso, isso dificulta o TDD (se você conhece XP, sabe do que eu estou falando, não é?), pois é difícil substituir as implementações por stubs de teste.
A gente não brinca com padrões, a gente os usa por necessidade.
Ah, está sim!
Tá, então implementa um sistema com controle transacional, que possa ser testado com jUnit, e que possa usar DAOs Hibernate ou JDBC (Hibernate pode não ser permitido em alguns provedores, por usar manipulação de bytecode), sem recompilação de código, e vamos comparar as soluções pra ver qual a mais simples.
E por favor, não me venha com argumentos absurdos, já estou cansando de ficar explicando de novo, e de novo, coisas que eu sei que você já sabe.
Tetsuo
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
vfpamp Offline
Posts: 6010
Polêmica é legal! :D Faz agente pensar um monte de coisa :D
De acordo!
Detesto ter duas formas de resolver as coisas! :D Marcos, tah aih? :D Daria para usar isso? :D
Ok, então para que adicionar IoC se há meios mais simples para fazer? :D
AbstractFactory?
TDD - Test Driven Development (Sem olhar, hein!) :D
Arquivos de configuração não são patentes do Spring :D
Pelo menos os que sabem o que é YAGNI neh? :D
Programação por interfaces... não to não :D
Sabia que existe replaceAll(), o Eclipse é bom nisso? :D heheheh xunxo mas é o mais simples....
Agora, se precisar usar as duas implementações ao mesmo tempo, aí você para e repensa como fazer. Até lá KISS!
Bom, o Baba tah implementado com abstração de prevalência e persistência em AbstractFactory. Se não se importares em olhar lá. :D Os testes também não existem, mas eu estou começando a fazer.
Assim que me restar um tempinho eu vou colocar o Hibernate nele.
[/quote]
O que é um argumento absurdo, que IoC é uma merda? :D
PS: Sem contar que o XML não é compilável, podendo causar erros em várias partes da aplicação. Mais uma fonte de erros.
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
vfpamp Offline
Posts: 6010
Só para relatar..
Impecílios de se adicionar tecnologias em grandes sistemas e grandes equipes:
- Toma-se tempo de alguém para dedicir e aprender a mexer no framework, claro, ninguém decide usar um um cara desses de uma hora para outra.
- Leva-se de seis meses a um ano para o domínio completo da tecnologia. Isso, se for colocado em produção. Testando o fluxo do cliente.
- O cara que pesquisou a tecnologia e domina ela será consultado de tempos em tempos. Erros, inconsistências, má configuração são as principais fontes.
- Toda a equipe que trabalha na camada que usa a tecnologia em questão tem que DOMINAR a tecnologia. E, francamente, já temos siglas e conceitos demais para dominar.
- Se você tem mais projetos para a mesma equipe e nenhum deles utiliza a tecnologia em questão, a equipe desaprenderá muito rápido, além de ficar desatualizada em relação a tecnologia.
- A tecnologia envolvida se torna mais uma fonte de erros em produção.
- Os implantadores e os atendentes terão que conhecer os documentos de configuração em XML do framework de IoC, em alguns casos, isso não é uma tarefa fácil.
- Depois de muito se debater em criar tudo isso seu software cairá em desuso.
Enquanto isso:
- Constrói uma Factory e cria um arquivinho simples de propriedades. Gera um manual de 2 páginas no máximo sobre o arquivo e manda pra todo mundo ler!
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
ronaldtm Offline
Posts: 2299
Polêmica demais faz a gente se perder num mar de opiniões, perdendo o foco no assunto principal.
Mais de uma forma permite o uso da melhor pra cada situação. Você escolheria ter um esquema simples, mas menos flexível, ou flexível, mas complexo? Muitas vezes não é possível obter as duas simultaneamente, então são oferecidas as duas formas. 'O que é simples deve ser simples, o que é complexo deve ser possível.'
Depende. Talvez a complexidade de se usar um framework IoC seja menor do que a soma da complexidade das soluções individuais de cada problema resolvido pela IoC.
Desculpe, eu não encontrei a fábrica abstrata no seu 'new MinhaClasseOverPower();'.
Ah, sim, esqueci. Daí, você vai brincar com padrões e adicionar a fábrica.
Se você colocar os 'new' dentro de cada classe, como você disse acima que não achava mal nenhum, tá fudido sim!
Não confio em 'Replace All'. Por experiência própria, a medida que o sistema vai crescendo, fica mais difícil fazer um regex que substitua só nos lugares corretos.
E ele tem controle transacional? Aliás, ele precisa de controle transacional? Que eu me lembre, ele era uma aplicação Swing. Ele tem uma parte servidor também? (puro desconhecimento, sorry).
Como eu já disse, frameworks afetam a arquitetura como um todo. Pode ser pra bem, pra mal, ou apenas uma opção de filosofia. O Spring daria um direcionamento à componentização e desacoplamento. Não sei como está a implementação do Baba, mas você tem a noção exata das dependências de cada classe? DI (vulgo IoC) permite isso, além de reduzir o custo da programação por interfaces (acredite, tem um custo, que pode se tornar bem alto) a quase zero.
Não, mas tem vezes que você levanta mais polêmicas com 'e se's, desviando do assunto.
Isso é verdade. Ainda bem que a configuração no Spring pode ser bem simples, além de que podemos 'ligar' um verificador de dependências, alterando um simples atributo no XML, que se assegura de que todas as dependências estão sendo satisfeitas. Além disso, é possível também configurar o Spring programaticamente, pois seu mecanismo de configuração é bem flexível.
Tetsuo
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
ronaldtm Offline
Posts: 2299
Certo, então vamos jogar todos esses frameworks prontos fora e voltar a implementar nossos próprios frameworks de MVC e persistência! (comentário sarcástico, ignore)
Concordo, claro que o foco não deve ser na tecnologia, mas sim no problema a ser resolvido. Mas eu acho que alternativas devem ser sempre consideradas e estudadas, pois senão ficamos estagnados, perdidos das inovações e novas idéias que possam realmente melhorar a qualidade dos nossos softwares.
Aqui um exemplo de argumento absurdo.
Tetsuo
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
volnei Offline
Posts: 2203
Já que o o Ronald já jogou todas as pedras no Vitor agora eu vou falar um pouquinho...
Eu tambem acho que a utilização de frameworks como o Primavera, deixam um projeto um pouco sujo. Não há nada que ele faça que não seja resolvido elegantemente com um Factory Method um Abstract Factory. A parte transacional é controlada pelo WW (ou pelo menos era, através de Interceptor) ele apenas carregas as DAOs, e outras necessidades de execução nas Actions e camadas envolvidas, porém a quantidade de XML gerada me faz pensar: -Em que isso vale realmente a pena? Pra mim o projeto fica mais dificil de ser debugado, uma vez que para isso é preciso conhecer detalhes da implementação de um framework para saber exatamente seu comportamento. Em outras palavras, é fácil quando o StackTrace te mostra uma erro em uma classe sua, você vai no código e faz as alterações necessárias, agora quando o erro é mostrado em uma classe do framework a coisa fica mais complicada.
Não sou totalmente contra a utilização de frameworks, mais eu acho que tudo deve ser dosado adequadamente, assim como disse o Vitor disse, não é porque uma coisa tá na moda que deve ser usada em todo e qualquer lugar. Pra mim, a quantidade de XML que precisa ser gerada para o Spring (não sei se existe xDoclet pra isso) acaba saindo 6 por meia dúzia com relação a uma programação usando outras patterns.
Bom pessoal, essa é minha opinião, não estou pedindo pra ninguem concordar comigo, mais se quiserem me mestrar que eu estou errado, por favor, não exitem.
[]'s
_________________
::volnei::
volnei Offline
Posts: 2203
Porque Ronald?
_________________
::volnei::
vfpamp Offline
Posts: 6010
Também pergunto isso...
Não to dizendo que é para jogar fora os frameworks, mas não me venha dizer que IoC é simples...
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
vfpamp Offline
Posts: 6010
Entre simplicidade e flexibilidade eu prefiro simplicidade!
Será? Acho muito difícil.
Bom, se você ACHAR que vai precisar criar uma independência é muito mais simples criar um Factory do que importar um Framework completo de IoC cheio de outras coisas que nunca vai passar pela sua cabeça usar
Meu... Já viu quanto tempo isso leva? 1 hora no máximo para alterar em um sistema grande. Isso se encaixa em qualquer orçamento.
Tem as transactions do Prevayler que vão virar Transações no Hibernate. E você não disse que precisava ter um servidor.
Eu sei. Pra não dizer que tudo é dependente, o que separa é uma linha no arquivo de properties que identifica qual modelo de persistência será utilizado.
Isso já é mais que o suficiente para prover essa independência.
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
lucastex Offline
Posts: 3748
Bom, vou dar a minha opiniao, (humilde, simples e talvez insignificante).... Concordo com o que o Volnei disse ai em cima. Não sou contra a utlização de Frameworks como o Spring, mas como ele mesmo disse, a do sistema acaba se tornando "inacessivel" para novos desenvolvedores... Talvez soh para novos? Não... para desenvolvedores com um pouco menos de conhecimento tb....
Querem um exemplo real? Olhem para mim, simplesmente depois de 47239847230984723 arquivos xml entrarem em vigor no javaBB definindo as injecoes e o resto de grandes mudancas, eu simplesmente me perdi, e com tudo que tava empolgado e tenha tentado, nao consegui acompanhar o projeto....
E olhem que eu tentei... Foi um balde de agua fria... ehaehahe
_________________
Lucas Teixeira .·.
lucas@ltvm.net
volnei Offline
Posts: 2203
Nada como um exemplo prático!
E onde foi a simplicidade? E oque aumentou em flexibilidade no JavaBB? Tudo que está sendo feito com os 47239847230984723 de arquivos XML de pelo menos 2000000 de linhas poderia ser resolvido com o method factory, não?
_________________
::volnei::
lucastex Offline
Posts: 3748
Olhem que interessante, está um pouco fora do contexto (nao eh o applicationContext nao...
olhem o que ele diz sobre a implementacao de IoC:
_________________
Lucas Teixeira .·.
lucas@ltvm.net
vfpamp Offline
Posts: 6010
No artigo do Martin fala que o PicoContainer também não tem xml pq é muito complexo.
Nada mal... pelo menos alguém já pensou mais simples
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
daltoncamargo Offline
Posts: 8772
Snif..
Bom, só para meter mais um pouquinho o "pau" no Vítor, pense que todo mapeamento de suas classes estão em um arquivo externo, nada de abrir o eclipse pra recompilar sua classe "factory", caso você faça uma nova implementação. Tudo bem, você poderia usar um XML como base de sua Factory correto? Sim, mas e porque não usar IoC ao invés desta gambiarra?
Você tomou como exemplo o OpenNuke (Marcos e seu xmlzão...), pena que nós não gravamos a batalha no MSN entre eu, o Ronald e o Marcos, tentando convencê-lo que o XML dele está enoooorme, e ficaria pouco manutenível na hora que um final user tentar modificar alguma coisa, tipo configuração do BD
É, parece que agora estamos tendo progresso, uma vez que ele vai olhar daqui a uma semana aquele XML e dizer:
-"Nossa, eu fiz isso?"
Marcos é brincadeira heim?
No bb estamos usando o autowire byName do Spring (Tks to Ronald), o que deixa ainda mais legal brincar de DI
Pessoas polêmicas acreditam que DI pode vir a atropelar o yagni, porém, quando você tem um padrão de projeto legal, sabe exatamente qual vai ser sua estrutura de classes, basta ir acrescentando componentes via DI na mesma, sem ter que passar pelo stress de encapsular o componente na lógica do teu projeto
_________________
Sugestão de Livros
vfpamp Offline
Posts: 6010
Pelas razões citadas no 4 post? E ainda troca-se uma linha de um arquivo de properties para várias linhas de um bosta de XML.
Além do mais, acho que o Lucas ainda ta perdido. E olha que é o Lucas hein... não é qualquer coisa...
[]s
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
daltoncamargo Offline
Posts: 8772
Argh!
No thanks, não uso drogas
_________________
Sugestão de Livros
ronaldtm Offline
Posts: 2299
Com a adição do Spring, foi acrescentado UM arquivo XML, que atualmente possui exatas 125 linhas (o xwork.xml tem 78
Excluindo os arquivos de mapeamento do Hibernate, o projeto todo tem 7 arquivos XML:
build.xml - Ant
project.xml - Maven (tentativa, não utilizado atualmente)
log4j.xml - Log4J
hibernate.cfg.xml - Hibernate (configuração)
xwork.xml - WebWork
applicationContext.xml - Spring
web.xml - Container web
Ah, sim, eu também adicionei um XML com as configurações de formatação de código do Eclipse, mas isso não entra na construção da aplicação.
A adição do Spring não adicionou tanta configuração assim ao projeto. Mas uma coisa que foi alterada foi a forma de se programar, pois agora temos os princípios de componentização a serem seguidos, ao invés de sair dando 'new' direto.
Talvez, o lucas tenha se perdido, porque, além de adicionarmos o Spring, também alteramos a estrutura de diretórios do projeto. Antes, a raiz do contexto web tava no raiz do projeto, o que facilitava a montagem do ambiente de desenvolvimento, mas deixava a estrutura do projeto confusa. Agora os diretórios de fontes estão separados e organizados, mas é preciso um passo extra pra rodar a aplicação, que é a construção com o Ant.
Tetsuo
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
volnei Offline
Posts: 2203
A pergunta que não quer calar...
OQUE ISSO TEM DE MELHOR DOQUE USAR UM FACTORY? QUAIS AS VANTAGENS? Até agora ninguem respondeu isso!
_________________
::volnei::
volnei Offline
Posts: 2203
[editado]
non sense
_________________
::volnei::
daltoncamargo Offline
Posts: 8772
Acho que você não entendeu ainda muito bem o espírito da 'coisa'.
Vamos tomar o exemplo do bb:
O DI do Spring não está servindo apenas para como uma factory (mesmo se estivesse sendo, já seria um ganho enorme), mas também com a componentização do código, onde agora o princípio básico é, componentizar!
Ao invés de termos um new ComponenteDataUtil(); dentro da nossa action, apenas temos um setter de uma Interface componente por ex(tudo bem, hoje nós não estamos usando interfaces nos componentes, mas esqueça isso), então você não precisa mais ligar a Action com a ComponenteDateUtil através de bytecode:
Ou seja:
Deixa que o spring faz isso pra vc :!:
Conseguiu entender melhor?
Cya!
_________________
Sugestão de Livros
daltoncamargo Offline
Posts: 8772
Bom, conhecer um framework, é o princípio básico para um profissional ser contrato em uma empresa
_________________
Sugestão de Livros
volnei Offline
Posts: 2203
Duas tentativas de respostas sem êxito. Você ainda não respondeu oque eu perguntei nos dois últimos posts
_________________
::volnei::
volnei Offline
Posts: 2203
Digamos, Hibernate, Struts..
_________________
::volnei::
junior.esnaola Offline
Posts: 472
Nossa, depois de todas estas explicações, porque você mesmo não lê a documentação do Spring e tira suas próprias conclusões?http://www.springframework.org/documentation.html
[]s
_________________
SCJP 1.4
SCJP 1.5
JavaFree.org
daltoncamargo Offline
Posts: 8772
+1
_________________
Sugestão de Livros
volnei Offline
Posts: 2203
Por um acaso os desenvolvedores do Spring são os donos da verdade? Não podem ser questinados? Acho que estamos em uma disussão aberta, pelo qual espero que você tenha lido antes de colocar esse "comentário".
Vamos perguntar para o Gavin se o Hibernate é bom!
Desculpa, mais sinceramente vocês não estão preocupados em responder as perguntas, mas sim e defender o framework.
E Junior, eu já li, ele funciona! E daí?
_________________
::volnei::
daltoncamargo Offline
Posts: 8772
Como você mesmo disse, pra que ficar re-inventado a roda? Documentação já existe pronta, e se vc não quer usar todo o "poder" do spring, coloca o spring.jar no teu projeto e usa só o DI dele, e além disso, você não terá apenas uma pessoa para consultar, mas milhares de pessoas mundo a fora que já usam essa tecnologia
_________________
Sugestão de Livros
vfpamp Offline
Posts: 6010
Claro, componentizar é maravilhoso exceto se você não precisa disso.
Conhecer frameworks só é bom para saber quando não usá-los
Mas estamos discutindo IoC ou DI como quiserem não o Spring.
Quem conseguir responder a pergunta:
Ganha um brinde!
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
vfpamp Offline
Posts: 6010
Reinventando a roda? Desde quando criar uma classe é reinventar a roda?
E se eu quiser uma roda menor?
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
junior.esnaola Offline
Posts: 472
Não cara, eu de maneira alguma estou tentando te convencer a usar Spring ou alguma outra coisa mas é que você está questinando a funcionalidade do framework, na bem da verdade, do conceito IoC, eu acho que se você já leu a documentação sobre Spring, não gosta da mesma, então não há o porque ficar discutindo com quem gosta, afinal, usar frameworks é como ter time de futebol, não se discute, e o que tenho visto você fazer, é só perguntar, perguntar, e perguntar, não comprovou que você usou e não gostou por isso, isso e aquilo.
[]s
_________________
SCJP 1.4
SCJP 1.5
JavaFree.org
daltoncamargo Offline
Posts: 8772
Bom, e se eu quiser usar NetBeans, Visual Café ou JDeveloper? Bom, aí é com vc, afinal, graças a Alá, somos desenvolvedores LIVRES (Javeiros) e temos centenas de opções para desenvolver um bom software, vai do engenheiro definir o que é melhor para o projeto
_________________
Sugestão de Livros
volnei Offline
Posts: 2203
Não estou questionando a funcionalidade, como eu disse, ele funciona, mais sim a utilidade. Porque você precisa aprender uma tecnologia nova que não te trás benefícios? É isso, eu não vejo benefícios em usar o Spring. Se funciona, é o mínimo, o problema é que estou tentando fazer alguem (que gosta e utiliza) me disse, olha ele é melhor por isso e por aquilo, desde que não sejam recursos alcançados com um Factory um Singleton ou qualquer outro pattern simples.
_________________
::volnei::
ronaldtm Offline
Posts: 2299
Se você não precisa de alguma forma de componentização, então é porque o sistema é tão ridículo que não vale a pena ser discutido.
Bom, muito bom, então porque você está querendo criar um?
Você sequer sabe o que é IoC exatamente?
E eu estou usando o Spring como exemplo, porque é o que eu conheço melhor.
Porque isso cobre apenas um caso de aplicação de um container leve, que é a criação dos objetos. Mas você desconsidera completamente a configuração, o ciclo de vida e o gerenciamento dos componentes.
Não estou dizendo 'não façam mais factories', mas sim, 'factories não resolvem todos os problemas necessários'. Digamos que o 'new' está para uma abstract factory assim como uma abstract factory está para um container DI.
Tetsuo
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
ronaldtm Offline
Posts: 2299
Olha, ele é melhor por isso:
- facilita a criação, configuração e montagem dos componentes
- cuida do ciclo de vida de um componente, por exemplo, se ele vai ser um singleton ou não.
- fonece uma forma simplificada de AOP
- promove a componentização
e por aquilo:
- se integra facilmente com qualquer outro framework
- não é invasivo como EJBs
- você pode usar apenas o que quiser
- possui, além do container, uma biblioteca imensa de classes que seguem a filosofia do framework. Você não precisa reimplementar um gerenciador de transações, basta configurar um interceptor, já incluso no pacote, com uma das opções de gerenciadores (para JDBC, JTA, Hibernate, JDO), também inclusas. Em suma, pra muita coisa, você não precisa codificar uma linha sequer, basta configurar seus componentes de negócio com as classes já existentes. Pra outras, basta usar uma classe do pacote que fornece uma interface bem mais simples de usar que a original (javamail, por exemplo).
Depois eu vejo se lembro de mais alguma coisa
Tetsuo
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
volnei Offline
Posts: 2203
Parecem crianças que ganharam um brinquedo novo. Antes de existir o Spring já eram desenvolvidos boas aplicações Ronald e vão continuar sendo desenvolvidas sem ele.
Quer saber, vocês falam, enrolam e não respondem nada, dizer que é bom tudo bem, mais em que é melhor eu ainda não vi.
E Ronald, desde quando precisa de Spring para componentização?
_________________
::volnei::
vfpamp Offline
Posts: 6010
Poisé... pelo menos eu estou tentando deixar todos os projetos que eu participo ridiculamente SIMPLES!
Tópico errado
Sim, quantos livros eu vou ter que ler para conhecer IoC? Cada vez isso fica mais complexo.
Imagino que adicionando configurações o XML tende a crescer, não?
Simplicidade?
Cliclo de vida o Java resolve sozinho
Exemplo prático, as DAOs do ON poderiam ser criadas com um Abstract Fatory, não precisam de gerenciamento, ciclo de vida ou configuração. Uso incorreto?
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
vfpamp Offline
Posts: 6010
Tem algo mais fácil que new XX( "Teste do Vitor" ); ? :D
Isso é no XML certo? Prefiro implementar um Singleton, que, lembrando é só mais um método estático na classe.
E quem disse que eu preciso disso?
Troque por força a componentização.
Componentização aumenta os custos com gerencia do projeto.
Preciso falar alguma coisa, quando estamos discutindo simplicidade?
...
Claro, depois de ler 5 livros e 10 tutoriais diferentes.
Biblioteca imensa de classes?
Gerenciador de Transações?
Algo assim?
O Pico Container também tem isso tudo? Lembrem-se, estamos discutindo IoC, não a bosta do Spring ::D
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
ronaldtm Offline
Posts: 2299
Sim, mas necessitavam de uma quantidade de trabalho bem maior.
Bom, eu respondi, se você não entendeu, não é problema meu.
Spring PROMOVE componentização.
Ah, não, cansei de vocês dois, chega. Vocês que parecem crianças, tampando os ouvidos e gritando 'não estou ouvindo, não estou ouvindo'. Fodam-se.
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
volnei Offline
Posts: 2203
- facilita a criação, configuração e montagem dos componentes [/color:3e88ccdd39]
Isso é oque mais foi discutido aqui, até um factory bem implementado facilita.
[color=blue:3e88ccdd39]- cuida do ciclo de vida de um componente, por exemplo, se ele vai ser um singleton ou não.[/color:3e88ccdd39]
E qual a vantagem? Implementar um singleton reutilizável é a coisa mais simples que tem.
[color=blue:3e88ccdd39]- fonece uma forma simplificada de AOP [/color:3e88ccdd39]
AOP nasceu antes do Spring, aliás, bem antes.
[color=blue:3e88ccdd39]- promove a componentização [/color:3e88ccdd39]
Já disse, a componentização não depende o Spring.
[color=blue:3e88ccdd39]- se integra facilmente com qualquer outro framework [/color:3e88ccdd39]
É o minimo, já pensou se não se integrasse?
[color=]- não é invasivo como EJBs
Não posso falar sobre isso, nunca trabalhei com EJB.
- você pode usar apenas o que quiser[/color:3e88ccdd39]
Eu já faço isso.
[color=]- possui, além do container, uma biblioteca imensa de classes que seguem a filosofia do framework. Você não precisa reimplementar um gerenciador de transações, basta configurar um interceptor, já incluso no pacote, com uma das opções de gerenciadores (para JDBC, JTA, Hibernate, JDO), também inclusas. Em suma, pra muita coisa, você não precisa codificar uma linha sequer, basta configurar seus componentes de negócio com as classes já existentes. Pra outras, basta usar uma classe do pacote que fornece uma interface bem mais simples de usar que a original (javamail, por exemplo).
Agora sim! Isso realmente é um vantagem!!!
_________________
::volnei::
Relacionados
Introdução: Inversion of Control http://javafree.uol.com.br/topic-8216-Introducao-Inversion-of-Control.html [JSF] Business Delegate e Service Locator http://javafree.uol.com.br/topic-856128-JSF-Business-Delegate-e-Service-Locator.html IoC com WW http://javafree.uol.com.br/topic-12093-IoC-com-WW.html Trabalha trabalha trabalha http://javafree.uol.com.br/topic-848846-Trabalha-trabalha-trabalha.html Actions do WW como parte do modelo. http://javafree.uol.com.br/topic-9641-Actions-do-WW-como-parte-do-modelo.html Os posts mais legais do JavaFree. http://javafree.uol.com.br/topic-857239-Os-posts-mais-legais-do-JavaFree.html Siglas e mais siglas http://javafree.uol.com.br/topic-6301-Siglas-e-mais-siglas.html Acegi: Framework de Segurança para o Spring http://javafree.uol.com.br/topic-850833-Acegi-Framework-de-Seguranca-para-o-Spring.html EJB3: Sai Service Locator entra Inversion Of Control http://javafree.uol.com.br/topic-853256-EJB3-Sai-Service-Locator-entra-Inversion-Of-Control.html