MentaContainer: IoC simples e rápido.

This message was edited 1 time. Last update was at 28/07/2010 01:15:46

Estou disponibilizando o MentaContainer, que é um framework de IoC simple, prático, rápido, sem XML e sem anotações. Suporta Injection, DI, Wiring, Singleton, blah, blah, blah, com a diferença de ser simples de usar e fácil de entender. É mais uma alternativa em relação ao Spring, Guice e PicoContainer.

Comparem com esses outros e coloquem seus comentários e sugestões.

http://www.seducaotecnologica.com.br/mentacontainer-ioc-simples-rapido/

-Sergio

PS: Quando você lê um livro, você gosta de ler um texto limpinho ou um texto repleto de anotações? Anotação = remendo de código.

Sergio, usa Generics no método get para não precisar fazer Casting

This message was edited 1 time. Last update was at 28/07/2010 01:40:23

peerless wrote:Sergio, usa Generics no método get para não precisar fazer Casting

O get pode retornar qualquer coisa... Não dá para configurar isso não... Só se vc tivesse passando o type como parâmetro, o que não faz parte da API que retorna beans por NOME...

Não tem como fazer isso:

ex:

?

This message was edited 1 time. Last update was at 28/07/2010 02:32:49

peerless wrote:Não tem como fazer isso:

ex:

public class Teste { public <T> T get(String name) { return (T) new Date(); } public static void main(String[] args) { Teste teste = new Teste(); Date date = teste.get("blablah"); } }

?

Funcionou bonito !!! Espero agora nunca mais me esquecer desse truque esperto. MUITO OBRIGADO !!!

Bacana, Sergio. Esse container será usado nas próximas versões do Mentawai?

JavaChild Membro desde: 21/06/2007 16:05:01 Mensagens: 147 Offline

Show de bola Sérgio, estava pensando em uma coisa junto ao mentawai, mas vc fez logo um independente... muito bom.
Agora pode ser até usado em projetos Desktop, e tambem da pra fazer nossos TEST CASE bem mais fácil, e tambem chamar ações fora do contexto/request de forma simples.

This message was edited 1 time. Last update was at 28/07/2010 11:42:22

Ataxexe wrote:Bacana, Sergio. Esse container será usado nas próximas versões do Mentawai?

A primeira idéia é essa. O Mentawai, como o Rufino falou, só suporta IoC dentro das actions, o que funciona bem para as actions, mas já para os test cases e chamadas assíncronas, não...

Claro que vc pode usar Spring, Guice ou outra coisa junto com ele para contornar esse problema, mas agora essa facilidade virá out-of-the-box com o MentaContainer.

GUJ Hacker Membro desde: 08/07/2007 00:08:14 Mensagens: 6395 Offline

saoj,

como você espera que seja o uso do MentaContainer?

qual é a vantagem dele sobre o PicoContainer?

já leu esse post do Uncle Bob?
http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion

This message was edited 3 times. Last update was at 28/07/2010 14:57:59

Lucas Cavalcanti wrote:
como você espera que seja o uso do MentaContainer?

O primeiro uso será dentro do Mentawai, como um case-proof. Hoje o Mentawai oferece IoC e AutoWiring dentro das actions, mas se você queria usar o container por fora de uma action, por exemplo para testes ou tasks assíncronas sem qualquer request por trás, você ficava na mão, isto é, tinha que instanciar e configurar os seus componentes na mão. Nada difícil mas feio. Claro que vc podia utilizar ele com Spring ou Guice, mas agora com esse container integrado vai ficar tudo transparente e abstraído. Basta pegar a referencia do container e partir para o abraço.

O MentaContainer é bem pequeno, não depende de nada e por ser totalmente baseado em configuração programática e sem annotations você pode integrá-lo de forma fácil a qualquer outro framework. Vc também pode utilizá-lo em seus projetos de forma não-obstrusiva.

qual é a vantagem dele sobre o PicoContainer?

Me parece que o pico container não registra os componentes por nome, apenas por type. Tente fazer aqueles exemplos básicos do MentaContainer com o Pico. Tenho minhas dúvidas se será tão simples...

já leu esse post do Uncle Bob?
http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion

Acabei de ler por alto. Mas ele critica IoC ??? Claro que qualquer coisa usada de forma errada, exagerada ou desnecessária será ruim, mas todo mundo hoje entende que IoC é essencial pra quase tudo.

GUJ Hacker Membro desde: 08/07/2007 00:08:14 Mensagens: 6395 Offline

saoj wrote:

Lucas Cavalcanti wrote:
qual é a vantagem dele sobre o PicoContainer?

Me parece que o pico container não registra os componentes por nome, apenas por type. Tente fazer aqueles exemplos básicos do MentaContainer com o Pico. Tenho minhas dúvidas se será tão simples...

Seu código:

Pico container:

é a mesma coisa, só muda o nome dos métodos... e o pico até é mais simples, pq vc não precisa pedir pra fazer o autowire: ele faz sozinho, já é suposto...
e sim, dá pra registrar componentes por nome (o código acima tá usando isso)

Cuidado pra não reinventar a roda.

saoj wrote:

Lucas Cavalcanti wrote:
já leu esse post do Uncle Bob?
http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion

Acabei de ler por alto. Mas ele critica IoC ??? Claro que qualquer coisa usada de forma errada, exagerada ou desnecessária será ruim, mas todo mundo hoje entende que IoC é essencial pra quase tudo.

ele não critica IoC, ele critica a necessidade de usar um Container de IoC para fazer coisas comuns, em que fazer na mão é muito mais fácil...

Containers IoC são bastante úteis qdo integrado a frameworks como o VRaptor, o Spring MVC, o proprio EJB com CDI...
usar um container na mão só pra instanciar objetos numa classe da sua aplicação é meio desperdício, usar o construtor da classe e fazer na mão é melhor!
é isso que o Uncle Bob está falando

This message was edited 9 times. Last update was at 28/07/2010 21:38:10

Legal, não sabia que suportava por nome tb, mas isso realmente me pareceu básico dele suportar. O exemplo da introdução no site deles não menciona isso e achei que por ser básico deveria aparecer ali. Então pensei que não suportava.

AutoWire totalmente automático é loucura. Funciona em hello world, mas em qualquer projeto maior vc vai começar a ter clash de dependencia. Por isso no MentaContainer isso é explícito por nome e type. Deixar apenas por type tem dois problemas:

1) Clash como eu falei

2) Demasiadamente custoso, pois agora vc tem que checar todas as propriedades de todo mundo e fazer um cruzamento entre todas as classes e suas propriedades. Quando vc define uma lista finita de dependencias isso fica bem mais simples e rápido.

Não sei se o Pico te permite especificar as dependencias. Provavelmente sim, mas olhei o javadoc deles e não encontrei nada como addDependency.

Mas tudo bem, podem usar o Pico ao invés do MentaContainer se assim desejarem. Vcs são livres pra isso. O PicoContainer é muito bom. Não sei porque o Google não usou o PicoContainer quando precisou de um container de IoC com configuração programática. Eles adoram re-inventar a roda por lá, a começar pelo próprio buscador...

Já pra mim valeu muito a pena porque o Mentawai suporta IoC e DI e AutoWiring desde 2005 quando foi lançado e eu apenas extraí essa funcionalidade num framework separado. Valeu como aprendizado e principalmente para fazer com que o Mentawai se torne um container de IoC genérico e não apenas para Actions. Claro que usando ele com Spring/Guice/Pico/XXX vc tb consegue isso, mas lembre-se que desde 2005, antes de Struts2, VRaptor2, VRaptor3, Seam, etc. o framework possui a filosofia de ser FULLSTACK, sem XML e sem Annotations. É isso que diferencia ele dos outros 10 milhões de frameworks. A roda fica diferente das outras porque tem sua própria integridade.

Ola

Vc poderia ter algo como

Cujo codigo pode ser

GUJ Hacker Membro desde: 08/07/2007 00:08:14 Mensagens: 6395 Offline

saoj wrote:Legal, não sabia que suportava por nome tb, mas isso realmente me pareceu básico dele suportar. O exemplo da introdução no site deles não menciona isso.

AutoWire totalmente automático é loucura. Funciona em hello world, mas em qualquer projeto maior vc vai começar a ter clash de dependencia.

Não concordo...
Se você faz Inversão de Controle do jeito certo, vc não tem ciclos de dependência, e portanto não tem clash...

saoj wrote:
Por isso no MentaContainer isso é explícito por nome e type. Deixar apenas por type tem dois problemas:

1) Clash como eu falei

clash é só qdo vc precisa instanciar uma classe mais de uma vez com configurações diferentes...
mas nesse caso será que o problema não está no design da sua aplicação?

saoj wrote:
2) Demasiadamente custoso, pois agora vc tem que checar todas as propriedades de todo mundo e fazer um cruzamento entre todas as classes e suas propriedades. Quando vc define uma lista finita de dependencias isso fica bem mais simples e rápido.

se a sua classe tem muitas dependências, de novo, o problema provavelmente está no design da sua aplicação!
se sua classe só tem 2 ou 3 dependências, não é tão mais custoso

Bom, boa sorte aí com seu framework novo, vc vai aprender bastante coisa com ele

[]'s

This message was edited 4 times. Last update was at 02/08/2011 11:26:45

Lucas Cavalcanti wrote:
Se você faz Inversão de Controle do jeito certo, vc não tem ciclos de dependência, e portanto não tem clash...

Clash não é ciclo, mas o caso que vc tem duas variáveis do mesmo tipo, ou que implementam a mesma interface, daí vc fica sem ter como saber qual que recebe o quê. Especificando explicitamente vc nunca terá esse problema porque vc especifica o tipo e o NOME da propriedade.

O problema de não especificar nada é que um objeto pode ter 100 propriedades mas apenas uma é uma dependencia que vai precisar de wiring. Melhor especificá-la pois vc ganha três vezes:

A coisa fica clara e vc sabe exatamente o que está dependendo de que.

Fica mais fácil (e rápido) para o container achar essa dependencia e injetá-la, isto é, não precisa checar cada uma das 100 propriedades.

Menos risco de vc injetar algo sem querer, porque o container achou uma propriedade na super.super.super.super class e calhou de ter algo parecido definido no container.

se a sua classe tem muitas dependências, de novo, o problema provavelmente está no design da sua aplicação!
se sua classe só tem 2 ou 3 dependências, não é tão mais custoso

Acho que vc misturou. A minha aplicacao provavelmente vai ter poucas dependencias e EXATAMENTE POR CAUSA DISSO não custa nada definí-las na mão ao invés de deixar o container adivinhá-las.

Menos linhas de código não é necessariamente melhor. As vezes é bom saber o que está acontecendo e manter o controle.

MentaContanier => http://forum.seducaotecnologica.com.br/posts/list/5.page

Notícias, artigos e o maior fórum brasileiro sobre Java