MentaContainer: IoC simples e rápido.

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

1 ano depois

saoj wrote:
O problema de não especificar nada é que um objeto pode ter 100 propriedades mas apenas uma é uma dependencia que vai precisar de wiring.

ignorando o problema do objeto ter 100 propriedades, nenhum dos IOC containers faz autowiring automático de setters. Alguns fazem de construtor, que eu acho bem positivo.

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

A propria classe tem que saber quais são as suas dependências, não um cara externo (Separation of Concerns)

saoj wrote:
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.

mais rápido ainda é usar o setter, já que vc vai ter que falar propriedade por propriedade

saoj wrote:
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.

pra isso existem testes de integração

saoj wrote:

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.

nesse caso é melhor usar setters então

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

concordo que não necessariamente é melhor. Mas com o autowiring vc também tem controle sobre o que está sendo injetado
(anotando o setter ou a propriedade, ou recebendo no construtor).

sobre o MentaContainer: ainda acho o PicoContainer bem mais simples, e se vc quer mais controle o Guice faz de um jeito bem mais legal.

Lucas Cavalcanti wrote:1 ano depois

Tive que gastar um tempo pensando para te responder direito.

A propria classe tem que saber quais são as suas dependências, não um cara externo (Separation of Concerns)

Isso faz sentido mesmo, mas daí teria que se partir para auto-wiring implicito via construtor ao invés de wiring explicito via setter. Talvez fosse o caso de se pensar nessa funcionalidade para o MentaContainer.

Como vc usa o PICO ou o GUICE com um web framework? Possuem esses o escopo THREAD com clearing de instancias, o que equivale ao escopo REQUEST?

// The container supports the two methods below:  
  
	/**
	 * Clear all cached instances for that scope. If you have a thread-pool for example you will
	 * want to clear the THREAD scope when your thread is returned to the pool. Because you have a thread
	 * pool you will have the SAME thread handling different requests and each request will need its own instances
	 * from the container. Therefore, each time you are done with a thread and it is returned to your thread-pool
	 * you can call clear to release the instances allocated and cached by the container. A web container and/or framework
	 * can use this feature to implement a REQUEST scope which is nothing more than the THREAD scope with clear. If the web
	 * container was not using a thread-pool, the THREAD scope would be equal to the REQUEST scope as each request would
	 * always be handled by a different thread.
	 *  
	 * It does not make sense to clear a NONE scope (the method returns doing nothing). You can clear a SINGLETON scope if necessary.
	 * 
	 * @param scope The scope to be cleared.
	 */
    public void clear(Scope scope);  
      
    /** 
     * Clear a single key from cache and return the instance that was cached. 
     *  
     * @param key The key representing the bean inside the container. 
     * @return The value that was cached and it is not anymore (was cleared) or null if nothing was cleared 
     */  
    public <T> T clear(String key);

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

o guice tem um subprojeto chamado guice-web que já tem os escopos de request e session...

o pico é lightweight, então vc que controla os escopos

a anotação @PreDestroy funciona para limpar os objetos em ambos os casos (e faz parte do java SE).

De novo, não precisa reinventar a roda, já está pronto.

This message was edited 1 time. Last update was at 02/08/2011 13:26:18

Lucas Cavalcanti wrote:
o guice tem um subprojeto chamado guice-web que já tem os escopos de request e session...

Excelente

o pico é lightweight, então vc que controla os escopos

Não vi o escopo thread lá com destroy/clear, mas talvez tenha escondido em algum lugar...

a anotação @PreDestroy funciona para limpar os objetos em ambos os casos (e faz parte do java SE).

Sou contra anotacoes. Prefiro implementar uma interface a anotar a minha classe, mas isso é gosto pessoal.

O que eu quero dizer é que o container tem que suportar o escopo REQUEST ( = THREAD + CLEAR) primeiro. Uma vez suportando isso a sua classe pode ser anotada ou pode implementar uma interface para que libere resources num destroy.

De novo, não precisa reinventar a roda, já está pronto.

Se for assim ninguém faz mais nada porque tudo já está feito. Por que o Google fez o Guice se já tinha PICO e Spring? Por que o google fez um search engine se já tinha Yahoo e Altavista? Por que fizeram Seam se já tinha Struts, JSF, blah? A beleza está nas diferencas sutis, nos detalhes de implementacao, na simplicidade, na documentacao... Re-inventar a roda é um termo depreciativo, pois sugere que o cara vai fazer uma coisa totalmente igual a outra... Difícil haver dos sistemas / frameworks iguais... Programacao e design de APIs pode ser uma arte.

Constructor X Setter Injection => http://blog.springsource.com/2007/07/11/setter-injection-versus-constructor-injection-and-the-use-of-required/

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

o pico implementa o que vc chamou de CLEAR.. é só dar um container.stop() que ele chama todos os destroys.

como eu disse, no pico é vc quem controla os escopos então é só colocar criar um pico no começo da request, e fechar no final.

Seguindo algumas dicas do pessoal aqui, principalmente do Lucas, estou lançando uma nova versão do MentaContainer, agora no endereço: http://www.mentacontainer.org

As principais mudanças foram o suporte a DI via construtor e auto-wiring via construtor e setter. O auto-wiring ficou bem limpo:

Também foi adicionado interceptadores para factories. As funcionalidades agora são:

Programmatic Configuration

Bean Instantiation through constructors

Bean Initialization through setters

Dependency Injection through constructors

Dependency Injection through setters

Auto-wiring through constructors and setters (very simple!)

Injection through setters so you can populate any external object with objects from the container

Instantiation through constructors so you can instantiate any external class with objects from the container

Support for SINGLETON and THREAD scopes, plus you can easily create REQUEST and SESSION scopes for web projects.

Generic Factories so you can easily turn anything into a object factory.

Interceptors for factories: onCreated, onDestroyed, useful for object pooling.

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