[quote=fabgp2001] No caso do Spring tem a opcao de escolher o tipo de wiring que será usado. Esse problema so ocorre quando wiring “byName” é usado o que não é aconcelhado pelo pessoal do Spring. Claro se nao usar ele a quantidade de configuracao cresce muito.
]['s[/quote]
Cara, na real todo mundo usa wiring “byName” e dificilmente auto-wire, eu nunca vi um projeto Spring que não fosse todo com wiring-by-name.
Minha maior birra com Spring era o tamanho monstruoso do xml, mas agora com o 2.0 isso mudou muito.
[quote=louds][quote=fabgp2001] No caso do Spring tem a opcao de escolher o tipo de wiring que será usado. Esse problema so ocorre quando wiring “byName” é usado o que não é aconcelhado pelo pessoal do Spring. Claro se nao usar ele a quantidade de configuracao cresce muito.
]['s[/quote]
Cara, na real todo mundo usa wiring “byName” e dificilmente auto-wire, eu nunca vi um projeto Spring que não fosse todo com wiring-by-name.[/quote]
Pois é, eu ja vi e é um saco de trabalhar. O ponto que eu quiz tocar nem foi se usam ou nao, mas sim que há a opcao. Claro que a facilidade do “byName” nao tem comparacao.
Poxa cara eu não vejo isso como algo ruim, pelo contrário, acredito que XML veio muito mais pra facilitar do que pra “piorar a vida” do desenvolvedor. Eu prefiro mil vezes fazer gerenciamento/configurações de transações e aop pelo Spring (declarativo) do que ter que fazer na mão ou annotations todos os códigos. Sim, há lugares que as anotações caem muito bem (vide hibernate3/ejb3) até mesmo as transações declarativas @Transaction, mas pra mim XML é muito necessário em várias casos
[quote=Leozin]
Poxa cara eu não vejo isso como algo ruim, pelo contrário, acredito que XML veio muito mais pra facilitar do que pra “piorar a vida” do desenvolvedor.[/quote]
Kra, sei lah, XML normalmente dá mais problema do que solução.
Quando c escreve algo errado no XML, normalmente vai dar um erro em Runtime que não tem nada a ver com o problema.
Eu ainda axo q a cada dia mais e mais projetos estão fugindo do XML.
Pode ser viagem minha, mas eu fujo do XML o tanto quanto possível!
Para o metodo configure() sem problemas. Mas dentro desse metodo vc vai ter que chamar outros metodos para configurar a coisa, e esses metodos tem que vir de algum lugar. CoC nao resolve aqui…
Acho que soh tem duas opcoes:
1 - Estende uma classe abstrata.
2 - Passa um Configurator como parametro de configure().
É impossivel você reusar algo q alguem fez sem criar algum tipo de depencia…
Antes uma fisica (implementar ou extender algo) do q uma metafisica (ah, o metodo tem q ser void, tem q receber como parametro xyz, tem q ter um atributo privado na classe chamado JJJ, etc)
E eu prefiro uma dependencia compilável do que uma não compilável! (Jogar dentro de um XML já era compilação, reflexão tbm)
Sérgio, não entendi a parte em negrito. Pode dar um exemplo com código?
Não acho que o Guice e o Spring sejam tão concorrentes assim. Afinal o Spring é uma stack para a criação de aplicações enquanto o Guice é apenas um framework para DI. Entendi alguma parte errado?
Sérgio, não entendi a parte em negrito. Pode dar um exemplo com código?
[/quote]
public MyModule {
public void configure() {
// como eu configuro aqui dentro alguma coisa ???
// nao tenho nenhum metodo para chamar, ou seja, nao posso fazer nada...
}
}
Opcoes:
Heranca
public MyModule extends AbstractModule {
public void configure() {
bind("asdfasdf").to("asdfsdaf");
}
}
Parametro
public MyModule {
public void configure(Configurator conf) {
conf.bind("asdfasdf").to("asdfsdaf");
}
}
Classe estatica (ruim demais)
public MyModule {
public void configure() {
Configurator.bind("asdfasdf").to("asdfsdaf");
}
}
Eu prefiro disparado a opcao 1).
Acho que criou-se um preconceito contra heranca injustificavel.
Dentro do seu modelo de negocios e entidades ela deve ser usada com parcimonia, talvez ate ser evitada em prol de composicao.
Mas quando temos actions, modulos, e essas outras coisas do framework para o framework, nao ha porque nao usar heranca.
Há sim: testabilidade e desvínculo do framework e da infra-estrutura, acoplamento, coesão e cogeneridade. Além disso herança dificilmente faz sentido fora de uso polimórfico num ponto de vista meramente técnico.
Mas voltando ao caso específico, eu não entendi seu exemplo. Vamos supor que eu tenha um módulo A que dependa de um módulo B.
Eu posso simplesmente utilizar metadados:
pseudocodigo:
@id("moduloA")
class A {
//CoC, eu sei que existe um modulo A logo posso padronizar o injetor
public void injectModuloA(){}
//ah, mas eu posso querer utilizar um outro nome, entao eu saio do padrao e uso uma anotação. meu container pode inferir o tipo da dependencia ou o ModuloA em camelcase
@injectmethod
public void setModuloA(){}
//Ok, mas eu quero usar um nome muito alienígena, código legado, por exemplo
@injectMethod("moduloA")
public void ipsunLorem(){}
}
Bem parecido com EJB 3.0.
É exatamente assim que o spring funciona, com configuração em metadados (se são XML ou pqp é outro papo). Fazer o módulo depender do framework é uma das principais falhas do Struts, por exemplo.
Note que se você precisa dar o bind de um componente num objeto qualquer você não está usando IoC, está usando Registry. Quem faz isso é o container.
Vc prefere se atrelar a uma classe herdando ela e ganhando de presente um monte de funcionalidades ou usar anotacoes atrelando do mesmo jeito?
Mais uma vez repito: estamos falando aqui de actions, modulos, registars e por ai vai. Nao estamos falando de modelo de negocio e suas entidades, que eh claro pra todo mundo que nao deve se atrelar a nada. Vejam novamente a classe MyModule e reparem que ela eh uma coisa do framework para ser usado com o framework e nada mais. Assim como um arquivo XML e as anotacoes o sao…
Acho que temos um anti-pattern aqui. Pegaram a heranca como bode-espiatorio…
Meu código não depende de absolutamente nada do framework, o que o deixa compeltamente desacoplado.
Um possível problema seria metadados. Metadados não deveriam ser considerados como vínculo entre um framework e um objeto, mas eu acredito que anotações estaticamente etipadas como as de Java são um problema.
Ainda não consegui dimensionar isso em um modelo real, então não tenho conclusões, mas o problema de um framework não-POJO como o que você citou eu e toda a comunidade já conhecemos há alguns anos, por isso surgiram Spring, EJB3.0, Java EE 5.0, Struts 2, etc, etc, etc
Então todo conceito de POJo é overkill para você Recomendo fortemente a leitura dos livros de Rod Johnson, Eric Evans e Bruce Tate.
Isso merece uma explicação com um pouco mais de contexto. Page-Jones define os domínios de um sistema (nada aver com Domain Model), entre eles temos Negócios e Aplicação.
O código de negócios seria aquele que mapeia as entidades do mundo real. O código da aplicação mapeia as operações que aqueles casos de uso realizam sobre estes objetos.
Os tais módulos dificilmente (a menos que num plugin para MVC, persistência ou sei lá) saem destes dois domínios e estes são os mais importantes apra uma aplicação.
Bem, como código importante ele deve ser testado, certificado, facilmente refatorável, flexível e uma outra pá de adjetivo. Se você vincula este código com um framework você perde boa parte destes.
Achei que era so eu que nao tinha gostado daquela parada.
[/quote]
Soh falta agora apresentar motivos ne?
Vc prefere se atrelar a uma classe herdando ela e ganhando de presente um monte de funcionalidades ou usar anotacoes atrelando do mesmo jeito?
Acho que temos um anti-pattern aqui. Pegaram a heranca como bode-espiatorio…[/quote]
A herenca ali naquele caso não passa de um heranca pra economia de codigo o que eu acho feio e não gosto. Outra coisa porque AbstractModule tem que ser abstrata? Porque nao fazer igual o Hibernate faz com a classe Configuration?
Module module = new Module()
module.bind(Foo.class).to(FooImpl.class).in(Scopes.SINGLETON);
Outra coisa ao invez de obrigar a fazer isso podiam ter uma configuracao automatica tipo o VRaptor faz com os components.
