Arquivo Discussoes de Programacao e Tecnologia 
Um container de IoC baseado na implementação do Mentawai, bastante simples de usar, configurar e entender. Suporta Wiring, Injection, Singleton, Factories, etc.
http://www.seducaotecnologica.com.br/mentacontainer-ioc-simples-rapido/
Uma alternativa diferente ao Spring, Guice e PicoContainer.
A filosofia é ser extremamente simples (KISS), don’t make me think, sem nunca suportar XML ou Annotations.
mais um, mais um… :roll:
É um pet project ou voce espera usar de verdade num projeto serio em producao?
Espero usar de verdade num projeto sério de produção. :roll:
Oi saoj. Qual vantagem vc percebe em não usar annotations?
saoj, foi você quem o implementou? Pretende transformá-lo em uma engine para o CDI?
Isso é uma discussão infinita, mas vamos lá:
:arrow: Isso é a minha opinião pessoal. Você também pode ter a sua.
:arrow: Vou começar pela [color=blue]vantagem[/color] de usar annotation: ela relaciona a configuração ao configurado, ou seja, ambos ficam num mesmo lugar, sendo mais fácil para você saber qual a configuração de um elemento X pois sua configuração está logo ali em cima.
Agoras as [color=red]desvantagens[/color]:
:arrow: Espalha a configuração pelo código inteiro, ao invés de deixá-la organizada em um arquivo central.
:arrow: Uma alteração na configuração vai forçar um full re-deploy da aplicação, ou seja, você vai ter que gerar o war / jar de novo e fazer o re-deploy.
:arrow: Anotação polui o código. Quando você lê um livro você prefere as páginas limpas ou cheias de anotações? Eu prefiro o texto limpinho, sem uma anotação a cada parágrafo.
:arrow: Anotação não é documentação como eu já ouvi gente falando. Anotação é código. Só que é um código meia-boca, cheio de limitações.
:arrow: Anotação muitas vezes se torna um remendo de código para corrigir alguma limitação da linguagem. Por exemplo: named method parameters.
:arrow: A alternativa é configuração programática, sem XML e anotações. Ela pode ficar separada da aplicação, ser compilada a parte, etc. E a configuração estática dentro dela (nome do banco, usuário, etc) pode ficar separada num arquivo properties.
That’s it. Enjoy! 
JSF não é minha praia… EJB tb não… Então provavelmente não…
Na minha opiniao, a vantagem supera todas as desvantagens.
Sergio, considere usar Groovy ou JRuby para simplificar a configuracao. Em vez de voce ter uma classe especifica que fica num pacote especifico, voce pode criar uma pseudo-DSL pra IoC.
Nao que eu ache uma boa ideia a criacao desse framework… mas todos nos somos livres pra criar o que nos bem entendermos
tsc tsc luca…
apagar comentarios já é algo complicado,
agora editar e ainda dar uma de “super engraçado” ? tsc…tsc…
Sim, mas nesse caso eu quero configurar em Java mesmo.
Claro. Eu sou livre para criar e vc é livre para usar… ou ignorar se preferir. O mercado é o melhor juiz. Em programação não há too-big-to-fail.
Do que seria o EJB 3 sem as anotações …
Inviável muitas configurações em XML. Tem muuitas desvantagens!
Além de ter muitas outras vantagens, com crtz superam em muito essas desvantagens aí … !!
Vc não leu até o final:
ainda prefiro o Guice e o Pico (que tambem tem config programatica). mas parabens pela iniciativa e pela discussao do tema!
parabens pela iniciativa, precisamos mesmo de diversidade, cade os testes ? - brincadeira :twisted:
Não faz DI pelo construtor?
Sim, suporta, mas a preferencia é usar setter.
E veja que wiring por construtor não faz sentido, pois quando vc interliga os componentes eles já devem estar inicializados e o container não tem como calcular de anti-mão todas as dependências para chamar um construtor. Ele vai injetando conforme vai encontrando dependências. Isso é auto-wiring (no caso do MentaContainer por nome e type).
Algum motivo em especial para preferir via setter?
Digo isso por que eu implementei um container de DI para Delphi onde suporto apenas injeção pelo construtor (o projeto é novo… eventualmente posso implementar isso), e queria saber quais as vantagens de fazer injeção pelo setter.
Inicialmente eu suportava injeção diretamente nos campos do objeto (ou seja, sem passar pelo construtor nem pelos setters), mas depois descartei isso pois vi que era furada trabalhar assim
O que seria o wiring a que você se refere? Seria outro termo para injeção?
Algum motivo em especial para preferir via setter?Digo isso por que eu implementei um container de DI para Delphi onde suporto apenas injeção pelo construtor (o projeto é novo… eventualmente posso implementar isso), e queria saber quais as vantagens de fazer injeção pelo setter.
Inicialmente eu suportava injeção diretamente nos campos do objeto (ou seja, sem passar pelo construtor nem pelos setters), mas depois descartei isso pois vi que era furada trabalhar assim
Tanto faz injetar por setter ou por construtor. Ambos tem vantagens e desvantagens. O MentaContainer suporta ambos. Agora wiring por construtor é esquisito pelo motivo acima. Eu particularmente prefiro por setter.
O Mentawai suportava injection direto em campo privado, mas no MentaContainer tirei isso, pois é muita mágica. Se uma propriedade pode ser setada externamente ela precisa declarar um setter e ser uma boa cidadã.
O mais comum é fazer injection por setter mesmo. É o que eu vejo por aí.
O que seria o wiring a que você se refere? Seria outro termo para injeção?
AutoWiring = Tudo pode depender de tudo, e quando o container retorna um bean ele já retorna ele populado / preenchido com outros beans. Exemplo: Container está configurado para prover Connection e MyDAO. MyDAO depende de connection. Quando vc pede o MyDAO ele te retorna uma instancia de MyDAO com uma Connection dentro, que ele tb procura (a connection) no container. Faz isso automaticamente (por nome e type), daí auto-wiring.
Agora DI é simplesmente inversão de controle, ou seja, o container é que tem o controle para criar e injetar as instancias ao invés do objeto que depende dela fazer um new. É o desacoplamento total. Vc pode fazer isso via construtor ou setting. É parecido mais diferente de auto-wiring.
É claro que se vc entendeu DI vai entender também que todo DI deve acontecer numa campo de tipo INTERFACE.
Pelo que eu entendi, você considera que em DI o container instancia a classe e retorna para você, mas sem considerar as dependencias da mesma.
Já no wiring, o container instancia a classe e ainda provê todas as dependencias que ela pode precisar.
É isso?
Se sim, então acho que não faz sentido chamar de DI. O container não injeta nada, só cria e retorna para alguem (e esse alguem sim, poderá injetar em algum lugar). No Emballo (o projeto que citei), faço esse wiring via construtor sem problemas. No GIN (Google Guice adaptado para o GWT) idem.
Se eu lhe entendi errado, peço que desconsidere o paragrafo acima
Pelo que eu entendi, você considera que em DI o container instancia a classe e retorna para você, mas sem considerar as dependencias da mesma.
Já no wiring, o container instancia a classe e ainda provê todas as dependencias que ela pode precisar.É isso?
Se sim, então acho que não faz sentido chamar de DI. O container não injeta nada, só cria e retorna para alguem (e esse alguem sim, poderá injetar em algum lugar). No Emballo (o projeto que citei), faço esse wiring via construtor sem problemas. No GIN (Google Guice adaptado para o GWT) idem.
Se eu lhe entendi errado, peço que desconsidere o paragrafo acima
Entendeu certo.
Realmente temos IoC, DI e Wiring. Isso que descrevi é IoC e Wiring. A parte de DI é o método Container.populate(Object). O MentaContainer suporta as 3 coisas. Faz injeção, wiring e instanciamento de beans (IoC).
Acho que não faz muito sentido falar de IoC sem DI e vice-versa. Um meio que complementa o outro.
A boa prática geral diz que injeção por construtor é bem mais elegante que por setter. Além de gerar menos código, exibe melhor a relação de dependência e não permite que o objeto esteja em estado inconsistente. É o que o pessoal chama do Good Citizen Pattern.
Aliás, achei curioso você citar uns posts aí pra cima o padrão do bom cidadão com setters. É justamente o contrário.
A boa prática geral diz que injeção por construtor é bem mais elegante que por setter. Além de gerar menos código, exibe melhor a relação de dependência e não permite que o objeto esteja em estado inconsistente. É o que o pessoal chama do Good Citizen Pattern.
Eu prefiro por setter. Há vantagens e desvantagens de usar construtores versus setters.
Aliás, achei curioso você citar uns posts aí pra cima o padrão do bom cidadão com setters. É justamente o contrário.
Estava falando de injetar em campo privado (sem setter ou construtor) e não em usar setter ou construtor.
Como já falei, tambem prefiro injeção pelo construtor.
Se um objeto MyDao PRECISA de um objeto Connection pra funcionar, não tem por que essa dependencia não ser passada no construtor.
Quando está escrevendo testes de unidade, é muito facil esquecer de chamar um setter para colocar uma dependencia. Já se for no construtor, você nem conseguiria compilar o código.
Ou então se esquecer de configurar a dependencia no container, ele vai simplesmente te entregar o objeto em um estado inconsistente. Se fosse no construtor, o container não conseguiria instanciar o objeto e iria ocorrer uma exceção
parabens pela criação… parece ser bem interessante, mesmo
A boa prática geral diz que injeção por construtor é bem mais elegante que por setter. Além de gerar menos código, exibe melhor a relação de dependência e não permite que o objeto esteja em estado inconsistente. É o que o pessoal chama do Good Citizen Pattern.
Eu prefiro por setter. Há vantagens e desvantagens de usar construtores versus setters.
oi saoj,
acho q ele ta querendo dizer q quando objetos são criados eles devem estar prontos para o uso.
quando ocorre a injeção por setter vc tem uma instancia inconsistente, que na verdade é corrigida posteriormente via setter.
[]s,
bob
Usar apenas ioc, faço na "unha"mesmo. Spring vai além do ioc, por isso o considero muito bom, quando não preciso usar EJB (e quase nunca se precisa mesmo).
A boa prática geral diz que injeção por construtor é bem mais elegante que por setter. Além de gerar menos código, exibe melhor a relação de dependência e não permite que o objeto esteja em estado inconsistente. É o que o pessoal chama do Good Citizen Pattern.Aliás, achei curioso você citar uns posts aí pra cima o padrão do bom cidadão com setters. É justamente o contrário.
Interessante Sergio,
no entanto gostaria de dar um voto positivo ao saoj, pois eu também já li algumas referências que diziam que haviam mais vantagens em se usar os setters. Confesso que não lembro as referências, só lembro que me convenceu.
Vocês podem achar doido, mas o tipo de injeção que eu mais gosto não é nem construtor e nem setter. Curto criar pequenas API`s que buscam o que eu quero dentro do container de DI. Assim não uso nem setter, nem construtor… e ainda fico livre para buscar uma dependência dentro de um método estático das minhas classes. Acho que assim consigo fazer um código mais limpo e aproveitar de forma mais inteligente os métodos estáticos dos meus objetos. Doidera, né? 
saoj, já pensou em usar uma abordagem parecida com a do EJB 3, em que as annotations podem ser sobrescritas por XML? E além disso, com EJB 3 você pode manter uma parte da configuração em annotation e outra parte em XML, mesmo para um único POJO. Eu gosto muito dessa abordagem por dar opções ao desenvolvedor e atenuar consideravelmente(ou até eliminar) o problema do full redeploy…
Ou seja, tu faz um second level de IoC! Hahahahaha! Isso que é ser fascinado por baixo acoplamento!
Documentação para a versão 0.9.4, com novas funcionalidades como escopo THREAD, clearable components, etc.