IOC Containers

[Pedro Nicholas Souza Alves]

Boa Noite pessoal,

Estava dando uma pesquisada sobre IOC Containers pra .Net e acabei
caindo em um post do Scott Hanselman (bem antigo:
http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx).

Gostaria de saber qual desses frameworks vc's utilizam nas suas
aplicações e o motivo pela qual o escolheu.

[Ricardo Lacerda Castelo Branco]

Boa Noite Pedro!

Eu utilizo o Ninject. Comecei a utilizá-lo por ser simples pra quem estava aprendendo (pelo menos eu achei na época) e uso ele até hoje. Utilizo há uns 2 anos e nunca senti falta de nenhuma facilidade extra que ele não tivesse.

Estou lendo o livro "Dependency Injection in .Net" do Mark Seeman e nele é utilizado 4 outros frameworks. No próximo projeto devo utilizar algum outro como experiência.


Ricardo Lacerda Castelo Branco
castel...@gmail.com

2012/2/2 Pedro Nicholas Souza Alves <pedronich...@gmail.com>

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Marcus Alexandre Silva]

"  No próximo projeto devo utilizar algum outro como experiência. "

#medo

[Rodrigo Silva de Andrade]

medo por que?

[Fernando Mondo]

Eu usei o Ninject no Site em Mvc mas a Infra disse que como ele precisa que tenha sido habilidato o fulltrust não poderia utiliza-lo, então migrei paro o AutoFac que pra mim não teve diferença alguma,...

[Carlos Abdalla]

Pq ninguem usa o Unit da propria MS ?

Abs

[Daniel Moreira Yokoyama]

Aqui usávamos o StructureMap, então mudamos para o Castle.Windsor. Ambos funcionam bem com o OpenRasta (API REST que usamos) e nos serviram muito bem.

Com relação a mudar para fazer experiências, eu aconselho muito a fazer isto. Como diz o velho ditado, quem só sabe usar martelo só consegue enxergar prego.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Vinicius Quaiato]

Aproveitando a deixa do Daniel eu dou outra dica: experimentem não usar containers de IOC. Tentem programar sem usá-los.

[Daniel Moreira Yokoyama]

Excelente.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Mário Meyrelles]

Uma desvantagem do Ninject é que ele te obriga a fazer o deploy da versão full do .NET 4.0. Ou seja, seu pacote de instalação aumenta bastante apenas por causa desta dependência. Eu fiquei puto com isso na época - não sei se hoje já consertaram esse problema.

Mas de resto, o Ninject tem atendido bem.

2012/2/3 Daniel Moreira Yokoyama <moreira....@gmail.com>

[Marcus Alexandre Silva]

Nunca usei (só para estudar).

Resposta ao #medo: Não tenho coragem de usar nenhum novo projeto para experiencias... Para colocar alguma coisa para meus clientes eu tenho que ter a certeza absoluta que a coisa é boa.

Em 3 de fevereiro de 2012 10:35, Vinicius Quaiato <vinicius...@gmail.com> escreveu:

[daniel carli]

se o framework é amplamente usasdo, deve ser coisa boa.. a questão é se você tirar alguma coisa de bom dele.

Daniel Carli

dcrlz.tumblr.com

[Mário Meyrelles]

Por quê? Você poderia desenvolver melhor?

2012/2/3 Vinicius Quaiato <vinicius...@gmail.com>

[Ricardo Borges]

Quanto a questão arquitetural da thread, eu listo 2 problemas:

1 - O código de aplicação não conhece IoC.
2 - O código de aplicação conhece o container IoC.

Concordam?


On 3 fev, 10:44, Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
wrote:

> Excelente.
>
> Atenciosamente,
>
> Daniel Moreira Yokoyama.

> @dmyokohttp://twitter.com/dmyoko
>
> Blogs:
> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)http://gettingsharper.wordpress.com/
>
> Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)http://eisocristo.wordpress.com

>
> Stay Sharp!
>
> Em 3 de fevereiro de 2012 10:35, Vinicius Quaiato <

> vinicius.quai...@gmail.com> escreveu:

>
>
>
>
>
>
>
> > Aproveitando a deixa do Daniel eu dou outra dica: experimentem não usar
> > containers de IOC. Tentem programar sem usá-los.
>
> > On Fri, Feb 3, 2012 at 10:14 AM, Daniel Moreira Yokoyama <
> > moreira.yokoy...@gmail.com> wrote:
>
> >> Aqui usávamos o StructureMap, então mudamos para o Castle.Windsor. Ambos
> >> funcionam bem com o OpenRasta (API REST que usamos) e nos serviram muito
> >> bem.
>
> >> Com relação a mudar para fazer experiências, eu aconselho muito a fazer
> >> isto. Como diz o velho ditado, quem só sabe usar martelo só consegue
> >> enxergar prego.
>
> >> Atenciosamente,
>
> >> Daniel Moreira Yokoyama.
> >> @dmyoko
> >>http://twitter.com/dmyoko
>
> >> Blogs:
> >> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
> >>http://gettingsharper.wordpress.com/
>
> >> Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)
> >>http://eisocristo.wordpress.com
>
> >> Stay Sharp!
>

> >> Em 3 de fevereiro de 2012 10:06, Carlos Abdalla <caabda...@gmail.com>escreveu:
>
> >>  Pq ninguem usa o Unit da propria MS ?
>
> >>> Abs
>

> >>> On Fri, Feb 3, 2012 at 8:52 AM, Fernando Mondo <fernando.mo...@gmail.com

> >>> > wrote:
>
> >>>> Eu usei o Ninject no Site em Mvc mas a Infra disse que como ele precisa
> >>>> que tenha sido habilidato o fulltrust não poderia utiliza-lo, então migrei
> >>>> paro o AutoFac que pra mim não teve diferença alguma,...
>
> >>>> Em 3 de fevereiro de 2012 08:39, Rodrigo Silva de Andrade <

> >>>> dangl...@gmail.com> escreveu:

>
> >>>> medo por que?
>
> >>>>> On Fri, Feb 3, 2012 at 8:05 AM, Marcus Alexandre Silva <
> >>>>> inf.marcusalexan...@gmail.com> wrote:
>
> >>>>>> "  No próximo projeto devo utilizar algum outro como experiência. "
>
> >>>>>> #medo
>
> >>>>>> Em 2 de fevereiro de 2012 23:30, Ricardo Lacerda Castelo Branco <

> >>>>>> castelobra...@gmail.com> escreveu:

>
> >>>>>> Boa Noite Pedro!
>
> >>>>>>> Eu utilizo o Ninject. Comecei a utilizá-lo por ser simples pra quem
> >>>>>>> estava aprendendo (pelo menos eu achei na época) e uso ele até hoje.
> >>>>>>> Utilizo há uns 2 anos e nunca senti falta de nenhuma facilidade extra que
> >>>>>>> ele não tivesse.
>
> >>>>>>> Estou lendo o livro "Dependency Injection in .Net" do Mark Seeman e
> >>>>>>> nele é utilizado 4 outros frameworks. No próximo projeto devo utilizar
> >>>>>>> algum outro como experiência.
>
> >>>>>>> Ricardo Lacerda Castelo Branco

> >>>>>>> castelobra...@gmail.com
>
> >>>>>>> 2012/2/2 Pedro Nicholas Souza Alves <pedronicholas.so...@gmail.com>

>
> >>>>>>>> Boa Noite pessoal,
>
> >>>>>>>> Estava dando uma pesquisada sobre IOC Containers pra .Net e acabei
> >>>>>>>> caindo em um post do Scott Hanselman (bem antigo:
>

> >>>>>>>>http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersI...
> >>>>>>>> ).

[Daniel Moreira Yokoyama]

Se você não tem um bom motivo pra usar IoC, não use.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Daniel Moreira Yokoyama]

Se vc vai pelo caminho do IoC, o ideal é que a camada mais alta conheça o Container.

E ninguém mais...

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Mário Meyrelles]

E o que seria um bom motivo para usar ou não usar? (desculpa a pergunta idiota)

2012/2/3 Daniel Moreira Yokoyama <moreira....@gmail.com>

Se você não tem um bom motivo pra usar IoC, não use.

[Daniel Moreira Yokoyama]

Estava explicando pro Quaiato em private:

Na maior parte das vezes, vc pode fazer a injeção por você mesmo, por exemplo, no controller vc pode conhecer a classe concreta que será injetada nos serviços de domínio. Ali, não há problema fazer isto sem envolver um container. Já está fazendo Inversion of Control sem envolver outra ferramenta (e mais uma complexidade).

No meu caso, eu uso o container não só pra injetar o tipo concreto... mas também pra gerenciar o lifecycle dos objetos que o container mantém. Então se eu preciso que determinado objeto seja singleton, o Windsor faz isso pra mim.

Outros objetos são gerenciados como uma instancia por sessão, ou uma instancia por request, etc, etc.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Cleber Dantas]

Acho que um ponto legal também de ser dito é a possibilidade do uso de Interceptors, pra quem gosta de isolar aspectos e "juntar" tudo depois é uma boa. Acho que nem todos os frameworks suportam isso.

Cleber Dantas
Cel: (11) 8272-4487

[daniel carli]

no caso do mvc, você pode até criar uma factory própria que injete a instancia pra vc.

Daniel Carli

dcrlz.tumblr.com

[Daniel Moreira Yokoyama]

Ou talvez você nem precise de nada disso.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Mário Meyrelles]

Entendi Daniel, agora ficou mais claro. Valeu pelos esclarecimentos. Com isso vi que eu pelo menos estou no mesmo entendimento que você. Muitas coisas que antes eu tinha que fazer no braço (como a história do lifecycle de objetos) acabaram sendo simplificadas com o container. E concordo plenamente que só a camada superior deve saber que o container existe. Eu tive a brilhante ideia de espalhar containers pelas camadas uma vez nos testes e vi que isso sim era uma péssima prática. Vou continuar usando o Ninject por enquanto...

[Vinicius Quaiato]

Só estou propondo um exercício... 

Se você só possui UMA classe concreta e cria uma abstração só para poder usar IOC/DI a coisa não tá indo muito bem...

Só um exercício mesmo...

[Mário Meyrelles]

Agree. Aí tem que ver isso aí nesse suposto caso...

2012/2/3 Vinicius Quaiato <vinicius...@gmail.com>

[Daniel Moreira Yokoyama]

For testability sake... se a classe em si é um proxy pra um serviço, ou pra acessar arquivos no filesystem, ou qualquer coisa que esteja fora do controle da aplicação, mesmo que seja uma única classe, a abstração precisa existir.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Vinicius Quaiato]

mas talvez não precise usar um container de ioc/di...

isso vaia acabar gerando um outro acoplamento em diveros pontos da app... e digo diversos pq já vi classe de negócios, sei lá tipo PedidoDeVenda fazendo chamadas para um container :P

Por isso o exercício...

[Daniel]

Simples,   bota todas as dependencias no webconfig e instancia na mao, hehe, activate

[Daniel Moreira Yokoyama]

Cara...

Qual o problema de instanciar usando o new e injetar na mão sem container e sem frescura?

É isso que o Quaiato tá falando.

E eu concordo. Até mesmo com relação às abstrações, que normalmente tb são desnecessárias.

Tenham em mente de que ninguém deveria usar um IoC se não tiver um motivo pra isto.

"Por que o Giovanni Bassi falou pra usar" não é um motivo.

Assim como também não vão sair por aí dizendo que "O Quaiato disse que IoC é um anti-pattern" hahuahuahuahu.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Daniel]

A minha resposta nao foi zuera ,   foi realidade,  na verdade tem tantos exemplos na net,   q as vezes confundem o desenvolvedor,   por isso e preciso saber a coisa,   e o pq da coisa antes de usat,  viva o activate

[Daniel Moreira Yokoyama]

Afff

[Daniel]

Aff nada,   fuja da moda camarada,   faz bem

Em sexta-feira, 3 de fevereiro de 2012, Daniel Moreira Yokoyama<moreira....@gmail.com> escreveu:

> Afff
>
> --aff

[Daniel Moreira Yokoyama]

Você pode fugir da moda sem inventar moda, camarada.

Se você precisa de um container, use o maldito container. Ele serve pra isto.

Reflection é oooooooooooooooooooooutra coisa (tente não usá-la de preferência).

Se você pode criar a instância usando reflection, aproveite pra criá-la usando new... é mais saudável.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

--

[Daniel]

Por isso tem muitos entrando na moda

Em sexta-feira, 3 de fevereiro de 2012, Daniel Moreira Yokoyama<moreira....@gmail.com> escreveu:
> Você pode fugir da moda sem inventar moda, camarada.

> Se você porprecisa de um container, use o maldito container. Ele serve pra isto.

[Daniel Moreira Yokoyama]

E outros inventando.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Robson Ramos]

Eu já utilizei o Unity em um projeto e pelo que precisei, não tive
problemas.

O único "problema" (que na verdade foi por falta de conhecimento) foi
o modo que inicialmente trabalhamos com ele (através de configuração
XML).
Depois mudamos tudo para código-fonte.

Att,

Robson Ramos

On 3 fev, 10:06, Carlos Abdalla <caabda...@gmail.com> wrote:
> Pq ninguem usa o Unit da propria MS ?
>
> Abs
>

> On Fri, Feb 3, 2012 at 8:52 AM, Fernando Mondo <fernando.mo...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Eu usei o Ninject no Site em Mvc mas a Infra disse que como ele precisa
> > que tenha sido habilidato o fulltrust não poderia utiliza-lo, então migrei
> > paro o AutoFac que pra mim não teve diferença alguma,...
>
> > Em 3 de fevereiro de 2012 08:39, Rodrigo Silva de Andrade <

> > dangl...@gmail.com> escreveu:
>
> > medo por que?
>

> >> On Fri, Feb 3, 2012 at 8:05 AM, Marcus Alexandre Silva <
> >> inf.marcusalexan...@gmail.com> wrote:
>
> >>> "  No próximo projeto devo utilizar algum outro como experiência. "
>
> >>> #medo
>
> >>> Em 2 de fevereiro de 2012 23:30, Ricardo Lacerda Castelo Branco <

> >>> castelobra...@gmail.com> escreveu:

>
> >>> Boa Noite Pedro!
>
> >>>> Eu utilizo o Ninject. Comecei a utilizá-lo por ser simples pra quem
> >>>> estava aprendendo (pelo menos eu achei na época) e uso ele até hoje.
> >>>> Utilizo há uns 2 anos e nunca senti falta de nenhuma facilidade extra que
> >>>> ele não tivesse.
>
> >>>> Estou lendo o livro "Dependency Injection in .Net" do Mark Seeman e
> >>>> nele é utilizado 4 outros frameworks. No próximo projeto devo utilizar
> >>>> algum outro como experiência.
>
> >>>> Ricardo Lacerda Castelo Branco

> >>>> castelobra...@gmail.com
>
> >>>> 2012/2/2 Pedro Nicholas Souza Alves <pedronicholas.so...@gmail.com>

>
> >>>>> Boa Noite pessoal,
>
> >>>>> Estava dando uma pesquisada sobre IOC Containers pra .Net e acabei
> >>>>> caindo em um post do Scott Hanselman (bem antigo:
>

> >>>>>http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersI...
> >>>>> ).

>
> >>>>> Gostaria de saber qual desses frameworks vc's utilizam nas suas
> >>>>> aplicações e o motivo pela qual o escolheu.
>

[Winston Pacheco Junior]

Cara, eu acho que alguém já postou comparativos (se não me engano aqui na lista mesmo) dos containers de IoC e o unity era a pior performance disparado... Minha internet tá muito lenta, não consegui fazer uma busca...

[Juan Lopes]

Eu estava usando o Guice para gerenciar as injeções numa aplicação linha de comando que estava fazendo (Java).

Um dia eu cansei dele e resolvi que iria injetar tudo na mão. Mas só fiz isso pq sei que é uma aplicação com poucas classes e eu precisava de um startup time bem baixo, por ser uma app linha de comando.

Hoje, meu IOC é isso ai:

https://github.com/intelie/lognit-cli/blob/master/src/main/java/net/intelie/lognit/cli/Main.java

Agora, Quaiato, discordo que você precise colocar uma dependência para o framework de IOC. Você só tem dependência se você usa service locator (o que é feio). Se você injeta via construtor, o IOC é completamente transparente.

2012/2/3 Winston Pacheco Junior <winston...@gmail.com>

[Anderson Lopes]

Segue o link: http://groups.google.com/group/dotnetarchitects/browse_thread/thread/cc52106784094562/02b8cf542f69e1ff?lnk=gst&q=Ioc+perfomance#02b8cf542f69e1ff

****************************************************************************************************************

Anderson Lopes

[Vinicius Quaiato]

vc não entendeu...

já vi coisas assim:

public class SomeDomainClassFoo {

    public void DoSomeDomainAction(){

        var needed = ContainerMalvado.Fetch<ISuperAbstractINterface>(); //SL like, ok

         needed.DoSomething();

         //bla bla bla

    }

}

Em uma app simples isso é verdade mesmo. Essa dependência deve ser promovida para o construtor e o container resolve a classe SomeDomainClassFoo... mas não é o que se vê por aí, por isso o exercício.

[Winston Pacheco Junior]

Justo, talvez eles já tenham corrigido isso, mas que é bizarro, é bizarro...

[Winston Pacheco Junior]

Pô Quaiato, esse exemplo é até bunitinho cara.

Eu já vi uma aplicação inteira WebForms que eles "injetavam" no construtor... kkkkkkkkkkkkkkkkk...

 

public class frm : Page {

    private Needed needed;

    public frm() {

        needed = ContainerMalvado.Fetch<ISuperAbstractInterface>();

    }

}

Claro, se isso era feito assim nessa classe, era feito assim em todas as classes, mesmo as que podiam ser injetadas no construtor, bla bla bla...

Era muito divertido, mas o arquiteto mandou... =P

[Ricardo Borges]

Juan,

Não conheço o Guice, mas já utilizei o http://picocontainer.org/.
Recomendo.

On 3 fev, 16:44, Juan Lopes <m...@juanlopes.net> wrote:
> Eu estava usando o Guice para gerenciar as injeções numa aplicação linha de
> comando que estava fazendo (Java).
>
> Um dia eu cansei dele e resolvi que iria injetar tudo na mão. Mas só fiz
> isso pq sei que é uma aplicação com poucas classes e eu precisava de um
> startup time bem baixo, por ser uma app linha de comando.
>
> Hoje, meu IOC é isso ai:
>

> https://github.com/intelie/lognit-cli/blob/master/src/main/java/net/i...

>
> Agora, Quaiato, discordo que você precise colocar uma dependência para o
> framework de IOC. Você só tem dependência se você usa service locator (o
> que é feio). Se você injeta via construtor, o IOC é completamente
> transparente.
>

> 2012/2/3 Winston Pacheco Junior <winston.pach...@gmail.com>

>
>
>
>
>
>
>
> > Cara, eu acho que alguém já postou comparativos (se não me engano aqui na
> > lista mesmo) dos containers de IoC e o unity era a pior performance
> > disparado... Minha internet tá muito lenta, não consegui fazer uma busca...
>

[Luiz Carlos Faria]

Então,

me questionei sobre isso faz um ou dois anos e cheguei à conclusão que você não precisa necessariamente criar um ponto de abstração forte. Se os princípios de Open/Close forem aplicados, você consegue obter a indireção necessária sem se preocupar durante o desenvolvimento.

E por muitas vezes você se questiona sobre o motivo de usar IOC em uma aplicação se você tem de fato poucas indireções fortes.

Uma das características que considero extremamente interessante ao usar um IOC é ter a capacidade de encarar cada classe como um serviço que, no seu ecossistema tem a função de prover funcionalidades por seus métodos. Entendo como estado de um serviço, sua configuração e esta por sua vez, determina variações em seu comportamento. Desta forma reaproveitar a mesma classe configurada de diversas formas diferentes torna o reaproveitamento algo muito interessante. 

Neste caso onde está o ganho? Aqueles que dependem desse comportamento, não precisam conhecer detalhes do comportamento que não é volátil à cada chamada. 

Bom, respondendo à pergunta da thread: Uso Spring.Net desde 2008 (e já usei vários tb)

_______________________________________________________________
Luiz Carlos Faria

[Luiz Carlos Faria]

Como sempre fui fã de aplicações distribuídas a flexibilidade de escolher a estratégia de deploy na hora da entrega representa uma flexibilidade impagável! Em uma época onde sequer o conceito do WCF havia sido publicado pela MS, o Spring.Net com o pacote de serviços já abstraía a estratégia de deploy. 

_______________________________________________________________
Luiz Carlos Faria

[Juan Lopes]

Concordo e discordo. Quando você deixa a relação entre duas classes ser puramente a referência que uma tem a outra, muitas vezes é difícil visualizar quais realmente são as mensagens que elas trocam.

Para mim, definir uma interface de comunicação é só um exercício de explicitar o que exatamente a minha classe precisa dessa dependência que ela está declarando.

2012/2/4 Luiz Carlos Faria <luizcar...@gmail.com>

[Daniel Moreira Yokoyama]

Isso é Interface Segregation.

É extremamente útil principalmente quando a dependência em questão não consegue manter o SRP.

Independente disso, o ganho precisa ser ponderado. Intention Revealing Interfaces é bastante útil, mas como o Quaiato tá dizendo, não é algo que se possa usar a torto e direito.

Pra variar, a melhor conclusão que podemos tirar de todas as coisas é que tudo depende.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Bruno Fiorentino]

Boa noite.

Gosto do Castle Windsor. Até a última vez que pesquisei era o mais completo e venho usando-o desde então. Outra vantagem é que depende do assembly Castle.Core, que contém o Castle Dynamic Proxy: prove suporte de AOP ao Windsor e também permite que voce crie seus proprios proxies e interceptors.

Aqui está um projeto onde uso Windsor para IoC/DI/AOP e também o Castle Dynamic Proxy separado: https://github.com/bfiorentino/P1

[]s

[Bruno Fiorentino]

Ao dar uma passada pelo http://servicestack.net/, acabei encontrando duas ferramentas para quem busca/precisa de minimalism/high performance/low memory footprint:

Funq "a fast DI container you can understand":

"Funq is by no means a revolutionary concept to DI, I’m well aware of that. But it’s one that takes a minimalistic approach to keep the performance impact of DI to a bare minimum. One of the project core requirements was to perform very well on the Compact Framework, as part of its inclusion in the upcoming Mobile Client Software Factory v2 from patterns & practices."

http://blogs.clariusconsulting.net/kzu/funq-screencast-series-on-how-to-building-a-di-container-using-tdd/

http://funq.codeplex.com/

MunQ:

Munq.DI is a very small, fast dependency injection container designed for ASP.NET applications, both Webforms and MVC. It has, by design, limited features. The main goal has been to minimize the CPU required for Resolving types from the container.
Take a look, the container.cs file is only 120 lines and the registration object code only 64.

http://munq.codeplex.com/

[]s

2012/2/7 Bruno Fiorentino <bruno.fi...@gmail.com>

[Mauricio Aniche]

Olá,

> Concordo e discordo. Quando você deixa a relação entre duas classes ser
> puramente a referência que uma tem a outra, muitas vezes é difícil
> visualizar quais realmente são as mensagens que elas trocam.

Concordo. E não consigo pensar de outra forma. Gosto de contratos bem
explícitos. Talvez esse seja meu problema com linguagens mais malucas
como Ruby ou Python. Pensando dessa forma, você sempre precisará de
alguém que injeta a dependência pra você. Da solução mais simples,
como uma Factory, até um framework de injeção de dependência, que faz
mágica.

A vantagem do framework é que, como o Daniel disse, ele pode te ajudar
em outras coisas estranhas como controlar ciclo de vida de objetos,
entre outros. A desvantagem é que os frameworks hoje fazem magia
negra, e permitem que você tenha grafos de dependências mais bizarros
possíveis (inclusive misturando objetos com diferentes ciclos de
vida!).

Sobre a sua solução, Juan, também já fiz isso. Meu projeto pessoal
atual, aliás, faz isso. Tenho fábricas, e elas sabem sobre as
dependências da minha classe. Alguém tem que saber. Não vejo problema
em esconder isso em um único lugar.

Portanto, sempre começo com factories (ou coisas mais simples), mas
não me sinto mal em colocar um framework de injeção de dependência um
pouco depois. Ainda mais se a infra ao redor, me ajuda (como é o caso
do Asp.Net Mvc, por exemplo, que te permite plugar qquer coisa).

Abraços,
Mauricio Aniche
@mauricioaniche

[Sebastian Andres]

Eu uso o Unity 2.0

Achei bem legal e fácil de usar. O lifetime do objeto é configurável via config então fica bem simples fazer ajustes dependendo da necessidade. Já usei ele em uns 4 projetos e não tive problema algum (por enquanto!)

[]s!

2012/2/3 Carlos Abdalla <caab...@gmail.com>

Pq ninguem usa o Unit da propria MS ?

Abs

On Fri, Feb 3, 2012 at 8:52 AM, Fernando Mondo <fernand...@gmail.com> wrote:

Eu usei o Ninject no Site em Mvc mas a Infra disse que como ele precisa que tenha sido habilidato o fulltrust não poderia utiliza-lo, então migrei paro o AutoFac que pra mim não teve diferença alguma,...

Em 3 de fevereiro de 2012 08:39, Rodrigo Silva de Andrade <dang...@gmail.com> escreveu:

medo por que?

On Fri, Feb 3, 2012 at 8:05 AM, Marcus Alexandre Silva <inf.marcu...@gmail.com> wrote:

"  No próximo projeto devo utilizar algum outro como experiência. "

#medo

Em 2 de fevereiro de 2012 23:30, Ricardo Lacerda Castelo Branco <castel...@gmail.com> escreveu:

Boa Noite Pedro!

Eu utilizo o Ninject. Comecei a utilizá-lo por ser simples pra quem estava aprendendo (pelo menos eu achei na época) e uso ele até hoje. Utilizo há uns 2 anos e nunca senti falta de nenhuma facilidade extra que ele não tivesse.

Estou lendo o livro "Dependency Injection in .Net" do Mark Seeman e nele é utilizado 4 outros frameworks. No próximo projeto devo utilizar algum outro como experiência.


Ricardo Lacerda Castelo Branco
castel...@gmail.com

[Pepeu]

Sei que não vou agregar nada de muito importante ao tópico mas minha opnião é a de simplificar TUDO sempre.
Vejo muita gente usando milhares de patterns em projeto que não precisa, vejo muita gente enfiando um monte de plugins/referências sem a menor necessidade.

Já vi cada bizarrice que dá até medo! Coisa sem sentido mesmo que nego bota pq acha bonito ou por que quer testar um novo framework, ou um novo plugin, etc...

Por isso saliento para qualquer coisa o "Use com moderação", seja IoC, seja DI, seja um simples Singleton, seja um Observer, Strategy ou qualquer coisa do tipo. :)

Abraços,
Pepeu

Abraços,
Pepeu

[Sebastian Andres]

Mas é assim mesmo Pepeu,

Tem que usar o que é preciso só quando for preciso. No meu caso os projetos em que trabalhei exigiam implementações específicas por cliente então com o IoC era muito fácil você dizer qual classe vai ser instanciada para uma interface em cada ambiente de instalação só alterando o config.

[]s!

2012/2/27 Pepeu <faleco...@gmail.com>

[Pepeu]

Exato Sebastian,
Por isso eu procuro tratar cada caso como um caso! :)
E outra, NÃO EXISTE CÓDIGO perfeito, eu considero a refatoração algo normal no dia-a-dia.

Não se apegar ao código e estar disposto a muda-lo e melhora-lo é o principal fator na minha opnião!
Se eu pegar um projeto que fiz a 1 ano atrás, eu com certeza faria diferente hoje, seja simplificando ou agregando coisas. :D

Eu sou meio desapegado ao código, em compensação sou muito apegado a idéias!

Abraços