MEF

[Thiago C. Santos]

Vi uma discussão aqui sobre o MEF, e pergunto... é incorreto usar o MEF como um Ioc/DI? 

Thiago C. Santos

[Jonathan]

Cara fique esperto com MEF... não sei como está a nova versão (se é
que já saiu), mas a primeira versão não tenho boas recomendações
devido a performance, de subir as dll's e sobrecarregar a memória.

Eu fiz um teste simples comparando o Unity do Enterprise Lib com MEF
com a mesma quantidade de objetos no container.

Alguns dizem que MEF não é container... outros usam como container...

On 30 nov, 13:06, "Thiago C. Santos" <thiago.csantos...@gmail.com>
wrote:

[Lucas]

Cara não sei se é incorreto, mas estou usando e funciona bem. Existe o
Unity tb, porém não tenho experiência com ele.

abs

lucas

On 30 nov, 14:06, "Thiago C. Santos" <thiago.csantos...@gmail.com>
wrote:

[Thiago C. Santos]

Então, o Unity esta me interessando bastante!

Estou implementando com Ioc/Service Locator.

Thiago C. Santos

2010/11/30 Lucas <lucassimo...@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

[Henry Conceição]

Se vc esta usando o ServiceLocator, ja começou errado.

E apesar de o Mef ser um IoC Container, ele é voltado p/ open
extensibility. Se sua aplicação demandar esse tipo de funcionalidade,
o Mef é o cara q vc esta procurando.

On Nov 30, 4:54 pm, "Thiago C. Santos" <thiago.csantos...@gmail.com>
wrote:

> Então, o Unity esta me interessando bastante!
>
> Estou implementando com Ioc/Service Locator.
>
> Thiago C. Santos
>

> 2010/11/30 Lucas <lucassimoesmais...@gmail.com>

>
> > Cara não sei se é incorreto, mas estou usando e funciona bem. Existe o
> > Unity tb, porém não tenho experiência com ele.
>
> > abs
>
> > lucas
>
> > On 30 nov, 14:06, "Thiago C. Santos" <thiago.csantos...@gmail.com>
> > wrote:
> > > Vi uma discussão aqui sobre o MEF, e pergunto... é incorreto usar o MEF
> > como
> > > um Ioc/DI?
>
> > > Thiago C. Santos
>
> > --
> > 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<dotnetarchitects%2Bunsu...@googlegroups.com>

[Juan Lopes]

Nossa, quanto dogmatismo.

Service Locator tem seu lugar no mundo, Henry.

2010/12/1 Henry Conceição <henry.c...@gmail.com>

--

Kind regards,
Juan Lopes 

http://juanlopes.net

[Ricardo Borges]

Um bom exemplo de uso do MEF é o próprio Visual Studio 2010... é possível customiza-lo criando apenas MEF extensions...

Ricardo Borges

[Thiago C. Santos]

Eu estou usando ServiceLocator com Unity e não com MEF, e pelo o que eu entendi o MEF não é um Ioc Container, por isto mesmo optei pelo Unity

Thiago C. Santos

2010/12/1 Ricardo Borges <ricard...@gmail.com>

[Henry Conceição]

So se for em lista de anti-patterns.

O servicelocator viola SoC e IoC simultaneamente.

On Dec 1, 12:26 pm, Juan Lopes <juanplo...@gmail.com> wrote:
> Nossa, quanto dogmatismo.
>
> Service Locator tem seu lugar no mundo, Henry.
>

> 2010/12/1 Henry Conceição <henry.concei...@gmail.com>

> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>

>
> > > > Para mais opções visite o grupo em
> > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > --
> > 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> > Para mais opções visite o grupo em
> >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> --

> Kind regards,
> *Juan Lopes *
>
> *http://juanlopes.net*

[Henry Conceição]

Pelo seu entedimento, qual a definiçao de um IoC Container entao?

On Dec 1, 1:29 pm, "Thiago C. Santos" <thiago.csantos...@gmail.com>
wrote:

> Eu estou usando ServiceLocator com Unity e não com MEF, e pelo o que eu
> entendi o MEF não é um Ioc Container, por isto mesmo optei pelo Unity
>
> Thiago C. Santos
>

> 2010/12/1 Ricardo Borges <ricardobor...@gmail.com>

>
> > Um bom exemplo de uso do MEF é o próprio Visual Studio 2010... é possível
> > customiza-lo criando apenas MEF extensions...
>

> > Em 1 de dezembro de 2010 11:26, Juan Lopes <juanplo...@gmail.com>escreveu:
>
> > Nossa, quanto dogmatismo.
>
> >> Service Locator tem seu lugar no mundo, Henry.
>

> >> 2010/12/1 Henry Conceição <henry.concei...@gmail.com>

> >>> <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>

>
> >>> > > Para mais opções visite o grupo em
> >>> > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>> --
> >>> 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> >>> Para mais opções visite o grupo em
> >>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >> --

> >> Kind regards,
> >> *Juan Lopes *
>
> >> *http://juanlopes.net*
>

> >>  --
> >> 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > --

> > Ricardo Borges
>
> >  --
> > 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

[Thiago C. Santos]

IoC você pode implementar com DI ou Service Locator,  assim como foi postado pelo Giovanni Bassi

http://unplugged.giggio.net/post/Injecao-de-dependencia-ou-Service-Locator.aspx

Thiago C. Santos

2010/12/1 Henry Conceição <henry.c...@gmail.com>

[Vinicius Quaiato]

Henry você foi infeliz nesse comentário:

SL é uma forma de IoC, como ele viola isso?

IoC é DIFERENTE de DI.

No momento em que o SL resolve a dependência ele está invertendo o controle (IoC).

E há casos onde usar um SL é a única opção plausível (por exemplo quando um WebForm do asp.net é criado e você precisa de alguns objetos. Não dá pra injetar. Mesmo que você use um container dentro do WebForm, ele está atuando como um SL).

Abraços,

Vinicius Quaiato.

2010/12/1 Henry Conceição <henry.c...@gmail.com>

[Henry Conceição]

Sim, eu sei que IoC e Di sao diferentes.

E infeliz é quem usa WebForms e precisa estuprar o design e violar
estes principios. E alem disso, so prova o meu ponto q se vc precisar
de ServiceLocator, vc falhou. Seja na escolha de algum framework (ex:
WebForms) ou no seu design.


On Dec 1, 3:02 pm, Vinicius Quaiato <vinicius.quai...@gmail.com>
wrote:

> Henry você foi infeliz nesse comentário:
>
> SL é uma forma de IoC, como ele viola isso?
>
> IoC é DIFERENTE de DI.
>
> No momento em que o SL resolve a dependência ele está invertendo o controle
> (IoC).
> E há casos onde usar um SL é a única opção plausível (por exemplo quando um
> WebForm do asp.net é criado e você precisa de alguns objetos. Não dá pra
> injetar. Mesmo que você use um container dentro do WebForm, ele está atuando
> como um SL).
>
> Abraços,
> Vinicius Quaiato.
>

> 2010/12/1 Henry Conceição <henry.concei...@gmail.com>

> > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>

>
> > > > > > Para mais opções visite o grupo em
> > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > > > --
> > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>
> > > > Para mais opções visite o grupo em
> > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > > --

> > > Kind regards,
> > > *Juan Lopes *
>
> > > *http://juanlopes.net*
>
> > --
> > 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

[Vinicius Quaiato]

Nem tudo é tão simples. Se você já tem aplicações e precisa manter, não existe mágica cara.

Nem sempre dá pra migrar, e nesses casos SL é uma solução sim.

Não gosto de WebForms e não uso, mas existem casos onde não é viável usar outra coisa. Como disse o Tucaz outro dia: Tenho projetos que faturam milhões e não posso simplesmente mudar de tecnologia.

E como eu disse em algumas palestras sobre MVC que dei: Talvez o único motivo aceitável para não usar MVC seja quando você já possui algo em WebForms.

2010/12/1 Henry Conceição <henry.c...@gmail.com>

[Henry Conceição]

Entendo a situaçao, mas isso imo nao muda o status do SL como sendo um
falha de design e/ou anti-pattern. É usar uma gambiarra (SL) pra
amenizar outra (WebForms).

On Dec 1, 3:19 pm, Vinicius Quaiato <vinicius.quai...@gmail.com>
wrote:

> Nem tudo é tão simples. Se você já tem aplicações e precisa manter, não
> existe mágica cara.
> Nem sempre dá pra migrar, e nesses casos SL é uma solução sim.
>
> Não gosto de WebForms e não uso, mas existem casos onde não é viável usar
> outra coisa. Como disse o Tucaz outro dia: Tenho projetos que faturam
> milhões e não posso simplesmente mudar de tecnologia.
>
> E como eu disse em algumas palestras sobre MVC que dei: Talvez o único
> motivo aceitável para não usar MVC seja quando você já possui algo em
> WebForms.
>

> 2010/12/1 Henry Conceição <henry.concei...@gmail.com>

> > > > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > > > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>

>
> > > > > > > > Para mais opções visite o grupo em
> > > > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > > > > > --
> > > > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>
> > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > > > > > Para mais opções visite o grupo em
> > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > > > > --

[Vinicius Quaiato]

Agora me diz, como você injeta uma dependência em um controller?

No MVC 2 usando um container de DI e controller factory. Bacana.

E como você resolve a dependência do container de DI na controller factory? Não dá!

Nesse ponto o container virou um SL. E aí?

2010/12/1 Henry Conceição <henry.c...@gmail.com>

[Henry Conceição]

Exceçao a regra ;-).

On Dec 1, 3:29 pm, Vinicius Quaiato <vinicius.quai...@gmail.com>
wrote:

> Agora me diz, como você injeta uma dependência em um controller?
> No MVC 2 usando um container de DI e controller factory. Bacana.
> E como você resolve a dependência do container de DI na controller factory?
> Não dá!
> Nesse ponto o container virou um SL. E aí?
>

> 2010/12/1 Henry Conceição <henry.concei...@gmail.com>

> > > > > > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
>
> > > > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
> > <dotnetarchitects%2525252Bu...@googlegroups.com<dotnetarchitects%252525252B...@googlegroups.com>

>
> > > > > > > > > > Para mais opções visite o grupo em
> > > > > > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > > > > > > > --
> > > > > > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>
> > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > > > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > > > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
>
> > > > > > > > Para mais opções visite o grupo em
> > > > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > > > > > > --

[Thiago C. Santos]

Henry, você esta partindo do ponto que SL é uma gambiarra porem este também é um pattern, não é o fato de que você escolha por usar ele ao inves de DI que você esteja errado, ambos são válidos. 

Acredito que quando se desenvolve a arquitetura existe os patterns que melhor atendam as necessidades do projeto. Cada projeto é um projeto, se existisse uma arquitetura que atendesse a todas as necessidades com a melhor performace e melhor implementação não existiriam discussões sobre arquitetura e patterns.

No meu caso eu escolhi o SL por que com este eu consigo atender melhor as minhas necessidades.

Se você acredita que SL é uma gambiarra então acredito que você ache toda e qualquer forma de POO uma gambiarra.

Thiago C. Santos

2010/12/1 Henry Conceição <henry.c...@gmail.com>

Exceçao a regra ;-).

[Henry Conceição]

Thiago,

Com SL vc ganha acomplamento - ja que suas classes conhecem
intimamente onde e quando resolver as dependecias - alem de assumir
responsabilidades complexas/error prone como o controle do lifetime.

Em 95% dos casos usar SL é um erro. Um erro principalmente cometido
por iniciantes. Por isso prefiro taxar ele de anti-pattern e nao
recomendar o seu uso.

E btw, o Mef é sim um IoC container, e nao conseguir reconhecer isto,
demonstra alguns gaps no seu conhecimento sobre o assunto.

On Dec 1, 4:06 pm, "Thiago C. Santos" <thiago.csantos...@gmail.com>
wrote:

> Henry, você esta partindo do ponto que SL é uma gambiarra porem
> este também é um pattern, não é o fato de que você escolha por usar ele
> ao inves de DI que você esteja errado, ambos são válidos.
>
> Acredito que quando se desenvolve a arquitetura existe os patterns que
> melhor atendam as necessidades do projeto. Cada projeto é um projeto, se
> existisse uma arquitetura que atendesse a todas as necessidades com a melhor
> performace e melhor implementação não existiriam discussões sobre
> arquitetura e patterns.
>
> No meu caso eu escolhi o SL por que com este eu consigo atender melhor as
> minhas necessidades.
>
> Se você acredita que SL é uma gambiarra então acredito que você ache toda e
> qualquer forma de POO uma gambiarra.
>
> Thiago C. Santos
>

> 2010/12/1 Henry Conceição <henry.concei...@gmail.com>

> > > > > > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
> > <dotnetarchitects%2525252Bu...@googlegroups.com<dotnetarchitects%252525252B...@googlegroups.com>
>
> > > > <dotnetarchitects%2525252Bu...@googlegroups.com<dotnetarchitects%252525252B...@googlegroups.com>
> > <dotnetarchitects%252525252B...@googlegroups.com<dotnetarchitects%25252525252...@googlegroups.com>

>
> > > > > > > > > > > > Para mais opções visite o grupo em
>
> >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > > > > > > > > > --
> > > > > > > > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>
> > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>

> ...
>
> read more »

[Thiago C. Santos]

Com SL você NÃO ganha acoplamento, as classes sabem quando resolver as dependências porem elas não sabem de onde vem a implementações. Quem sabe qual é a implementação de um abstração é o SL, ou seja, a responsabilidade é do SL.

Não acredito que usar SL seja um erro, muito menos coisa de iniciantes. Acho que você deveria ver o link que eu lhe mandei para aprender um pouco sobre SL, alias neste link demonstra o SL como uma opção valida e quem diz isto tem credibilidade na comunidade dos desenvolvedores .Net:

http://unplugged.giggio.net/post/Injecao-de-dependencia-ou-Service-Locator.aspx

MEF pode ser usado como IoC container porem este não foi feito para este propósito, ele foi criado com o propósito de facilitar estender as funcionalidades de uma aplicação já desenvolvida.

Acredito que não confrontar os próprios paradigmas seja um sinal de imaturidade ou ignorância.

Thiago C. Santos

2010/12/1 Henry Conceição <henry.c...@gmail.com>

[Pedro Reys]

Thiago,

Com SL você ganha acoplamento sim, ou sua classe não está, agora, acoplada ao Service Locator?

Com SL suas dependências ficam opacas e fica mais complicado de testar o seu código.

Sem entrar em flame baits,o uso de Service Locators, como dito pelo Henry, são, normalmente, um code smell. Pode ser que seja a única opção viável no momento, mas não deixa de ter seus problemas.

Uma última coisa, apelo à autoridade não fica muito bonito não.

- Pedro Reys

2010/12/1 Thiago C. Santos <thiago.csantos.me@gmail.com>

[Ricardo Borges]

Existe a possibilidade de um HttpModule ser usado para "injetar" componentes num webform.

Exemplo:

http://code.google.com/p/sneal/source/browse/trunk/AspNetWindsorIntegration/Sneal.AspNetWindsorIntegration/AspNetDependencyBuilderModule.cs

Tem um custo razoavel, já que precisa verificar os attributes via reflection na Page e em todos os controls da Page (usercontrols etc)

Mas, essa foi a abordagem que usei para não sair espalhando chamadas de um SL numa aplicação webform.

--
Ricardo Borges

[Vinicius Quaiato]

Pois é, o acoplamento existe, e pode ficar complicado de testar em termos.

O SL pode ser alterado nos testes (setters, etc).

A questão é que o SL é uma opção quando DI não é.

E em última análise os containers acabam atuando como SL.

Então dizer "SL é anti-pattern e não deve ser utilizado" é no mínimo um erro.

Claro que optar por SL ao invés de DI quando há essa opção não é muito interessante. Mas vale lembrar que constructor injection não é a única forma de usar DI, e não é mesmo.

É muito comum trabalhar com "setter injection" e valores default, e o SL pode atuar com esses valores default por exemplo.

É preciso analisar as situações. Não costumo usar SL, mas eles possuem sua serventia em alguns casos sim.

Afinal se uma dependência que não é mandatória pode ter um valor default, vocês fazem oq? Acoplam ao tipo concreto ou chama o container para resolver? Isso é SL.

Ou então vocês obrigam toda e qlqr dependência a ser passada no construtor? (isso tbm é um smell).

Existem 3 tipos(pelo menos) de dependências, e cada uma é resolvida melhor de uma maneira.

Abraços,

Vinicius Quaiato.

2010/12/1 Pedro Reys <pedr...@gmail.com>

[Vinicius Quaiato]

Não estou entendendo esse ódio todo ao SL.

Quando vocês usam containers de IoC/DI na aplicação estão usando um SL. 

Nem todas as dependências são resolvidas via construtor. Nem toda dependência é mandatória.

Se você coloca todas as dependências no construtor, vai ter problemas para testar.

Você testou seus webforms? Se não testou, esse HttpModule aí é apenas mais uma gambiarra em um código sem testes...

Lembrem-se, cada tipo de dependência é resolvida de uma maneira diferente, e constructor injection não é a única!

2010/12/1 Ricardo Borges <ricard...@gmail.com>

[Pedro Reys]

Quaiato,

É diferente você usar SL em um ponto único, ou em poucos pontos, da aplicação para resolver o container a usar SL espalhado por toda sua aplicação para fazer resolução de dependências.

Você pode me dizer quais problemas de testabilidade eu teria como consequência de usar constructor injection para todas as dependências?

- Pedro Reys

2010/12/1 Vinicius Quaiato <vinicius...@gmail.com>

[Ricardo Borges]

Esse é o ponto, não é possível implementar um unit test para um webform sendo este acoplado ao contexto web. Ou seja, a gambiarra primordial é o webform por si só. E o principal erro é de projeto. (a escolha do webform)

O contexto que eu citei o exemplo é o seguinte: o que fazer pra melhorar uma aplicação webform utilizando os conceitos de IoC?

ps: O http module que eu tomei de exemplo não usa constructor injection, até pq é impossível fazer isso com um System.Web.UI.Page. Ele "encontra" as propriedades do webform que possuem atributos que sinalizam para o SL injetar algo.

Se eu bem me lembro, o Spring.NET também usa essa abordagem pra tentar melhorar um pouco o webform

[Vinicius Quaiato]

Ué... se todas as dependências, mesmo as não obrigatórias para o sut precisam ser informadas no construtor você tem problemas de design.

Nem todas as dependências são mandatórias, assim sendo, as não mandatórias deveriam ser setadas de forma diferente de constructor, e setadas apenas quando necessárias.

Eu até iria um pouco mais além, e diria que jogar todas as dependências no construtor é um erro comum de quem acaba de aprender DI e IoC, afinal nem tudo aquilo é primordial para o objeto, e não será utilizado.

No teste você tem um overhead de criar todas estas dependências ou então ficar passando null para elas. (ainda que este null esteja em uma variável bem nomeada, é feio, smell).

2010/12/1 Pedro Reys <pedr...@gmail.com>

[Sidney Lima Filho]

Concordo Vinicius, as vezes estamos tão focados em garantir a SRP e nem percebemos que estamos entupindo nossos objetos de bugigangas tecnologicas desnecessárias. Não vejo o SL como o lado negro da força, ele apenas tem um custo, que é até aceitável para a utilidade que ele oferece. Temos atualmente dentro do próprio .NET Framework inumeros SL, Eu normalmente utilizo uma mistura dos 3 tipos de DI, de acordo com a necessidade do objeto. Pedro, não diria que você teria problemas de testabilidade, porém fica nítido que uma aplicação que passa TODAS suas dependencias por constructor que tem algo errado pois pode aparecer bizarrices, de exisitr um objeto com 15 metodos, com 15 argumentos no construtor só porque cada metodo usa uma dependencia diferente. Atenciosamente Sidney Lima Filho  Vivina Softhouse (0xx21) 7867-2321 55*10*68934 BLOG: http://blog.vivina.com.br   |    http://twitter.com/vivina

2010/12/2 Vinicius Quaiato <vinicius...@gmail.com>

[Pedro Reys]

Sidney, nesse caso a quantidade de dependências no construtor é mais um smell de bad design do objeto em si. Talvez esse objeto esteja fazendo coisas demais e possa ser dividido, não?

Usar SL ou Property Injection nesse caso seria varrer a sujeira pra debaixo do tapete. 

- Pedro Reys

2010/12/2 Sidney Lima Filho <sidney...@vivina.com.br>

[Juan Lopes]

Service Locator é mais intuitivo de ser usado que Dependency Injection, mas não deve ser usado em todo lugar, pois tem efeitos colaterais sérios a longo prazo (como as dependências pouco explicitas). Eu acredito nisso. Martin fowler também fala isso (como se não faltassem citações dele nesse grupo).

Não existe uma única forma certa de pensar justamente porque cada caso é um caso. Dogmatismo normalmente leva a projetos que só agradam um arquiteto.

2010/12/2 Pedro Reys <pedr...@gmail.com>

--

[Sidney Lima Filho]

Claro que objeto pode ser dividido, mas a sensibilidade do desenvolvedor para identificar que o objeto está com mais de uma responsabilidade é a mesma que faz ter vontade de desacoplar algo. Sem dúvida, nesse caso qualquer solução seria varrer para debaixo do tapete, porém não podemos esquecer de que quem está fazendo nunca acha que seu codigo é smell, só vai achar depois de algum tempo passado quando ele reavalia com outro raciocínio. Para não dizerem que não citei o Fowler também! Eu trabalho com dois  projetos em ASP.NET WebForm que literalmente sustentam a empresa, eu adoraria mudar tudo para MVC, porém tenho muito código legado, atualmente estou ainda implantando a cultura de TDD aqui na empresa para aumentar minha segurança de migrar aos poucos, porém ainda tenho muitas coisas bizarras siamesas de tão acopladas que estão. Na minha situação é Constructor Injection em tudo que posso e SL quando necessário, no meu caso geralmente é na interface.

Atenciosamente Sidney Lima Filho  Vivina Softhouse (0xx21) 7867-2321 55*10*68934 BLOG: http://blog.vivina.com.br   |    http://twitter.com/vivina

2010/12/2 Pedro Reys <pedr...@gmail.com>

Sidney, nesse caso a quantidade de dependências no construtor é mais um smell de bad design do objeto em si. Talvez esse objeto esteja fazendo coisas demais e possa ser dividido, não?

Usar SL ou Property Injection nesse caso seria varrer a sujeira pra debaixo do tapete. 

- Pedro Reys

2010/12/2 Sidney Lima Filho <sidney...@vivina.com.br>

2010/12/2 Vinicius Quaiato <vinicius...@gmail.com>

[Henry Conceição]

E com dependencias nao obrigatorias, nao fica claro qdo determinado
service pode ou nao ser consumido. Vc precisa saber de antemao se
naquele context x,y e z foram resolvidos, o q diminui a
previsibilidade do codigo.

On Dec 2, 1:31 pm, Pedro Reys <pedror...@gmail.com> wrote:
> Sidney, nesse caso a quantidade de dependências no construtor é mais um
> smell de bad design do objeto em si. Talvez esse objeto esteja fazendo
> coisas demais e possa ser dividido, não?
>
> Usar SL ou Property Injection nesse caso seria varrer a sujeira pra debaixo
> do tapete.
>
> - Pedro Reys
>

> 2010/12/2 Sidney Lima Filho <sidney.fi...@vivina.com.br>

>
>
>
> > Concordo Vinicius, as vezes estamos tão focados em garantir a SRP e nem
> > percebemos que estamos entupindo nossos objetos de bugigangas tecnologicas
> > desnecessárias.
>
> > Não vejo o SL como o lado negro da força, ele apenas tem um custo, que é
> > até aceitável para a utilidade que ele oferece. Temos atualmente dentro do
> > próprio .NET Framework inumeros SL,
>
> > Eu normalmente utilizo uma mistura dos 3 tipos de DI, de acordo com a
> > necessidade do objeto.
>
> > Pedro, não diria que você teria problemas de testabilidade, porém fica
> > nítido que uma aplicação que passa TODAS suas dependencias por constructor
> > que tem algo errado pois pode aparecer bizarrices, de exisitr um objeto com
> > 15 metodos, com 15 argumentos no construtor só porque cada metodo usa uma
> > dependencia diferente.
>
> > Atenciosamente
>

> > Sidney Lima Filho* *

> > Vivina Softhouse
> > (0xx21) 7867-2321
> > 55*10*68934

> > BLOG:http://blog.vivina.com.br<http://www.vivina.com.br/>   |
> >http://twitter.com/vivina<http://twitter.com/sidneyfilho>
> >  2010/12/2 Vinicius Quaiato <vinicius.quai...@gmail.com>

>
> > Ué... se todas as dependências, mesmo as não obrigatórias para o sut
> >> precisam ser informadas no construtor você tem problemas de design.
>
> >> Nem todas as dependências são mandatórias, assim sendo, as não mandatórias
> >> deveriam ser setadas de forma diferente de constructor, e setadas apenas
> >> quando necessárias.
>
> >> Eu até iria um pouco mais além, e diria que jogar todas as dependências no
> >> construtor é um erro comum de quem acaba de aprender DI e IoC, afinal nem
> >> tudo aquilo é primordial para o objeto, e não será utilizado.
> >> No teste você tem um overhead de criar todas estas dependências ou então
> >> ficar passando null para elas. (ainda que este null esteja em uma variável
> >> bem nomeada, é feio, smell).
>

> >>  2010/12/1 Pedro Reys <pedror...@gmail.com>

>
> >>> Quaiato,
>
> >>> É diferente você usar SL em um ponto único, ou em poucos pontos, da
> >>> aplicação para resolver o container a usar SL espalhado por toda sua
> >>> aplicação para fazer resolução de dependências.
>
> >>> Você pode me dizer quais problemas de testabilidade eu teria como
> >>> consequência de usar constructor injection para todas as dependências?
>
> >>> - Pedro Reys
>

> >>> 2010/12/1 Vinicius Quaiato <vinicius.quai...@gmail.com>

>
> >>>>  Não estou entendendo esse ódio todo ao SL.
>
> >>>> Quando vocês usam containers de IoC/DI na aplicação estão usando um SL.
>
> >>>> Nem todas as dependências são resolvidas via construtor. Nem toda
> >>>> dependência é mandatória.
> >>>> Se você coloca todas as dependências no construtor, vai ter problemas
> >>>> para testar.
>
> >>>> Você testou seus webforms? Se não testou, esse HttpModule aí é apenas
> >>>> mais uma gambiarra em um código sem testes...
>
> >>>> Lembrem-se, cada tipo de dependência é resolvida de uma maneira
> >>>> diferente, e constructor injection não é a única!
>

> >>>> 2010/12/1 Ricardo Borges <ricardobor...@gmail.com>

>
> >>>> Existe a possibilidade de um HttpModule ser usado para "injetar"
> >>>>> componentes num webform.
>
> >>>>> Exemplo:
>

> >>>>>http://code.google.com/p/sneal/source/browse/trunk/AspNetWindsorInteg...

>
> >>>>> Tem um custo razoavel, já que precisa verificar os attributes via
> >>>>> reflection na Page e em todos os controls da Page (usercontrols etc)
>
> >>>>> Mas, essa foi a abordagem que usei para não sair espalhando chamadas de
> >>>>> um SL numa aplicação webform.
>
> >>>>> Em 1 de dezembro de 2010 14:19, Vinicius Quaiato <

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

>
> >>>>>>  Nem tudo é tão simples. Se você já tem aplicações e precisa manter,
> >>>>>> não existe mágica cara.
> >>>>>> Nem sempre dá pra migrar, e nesses casos SL é uma solução sim.
>
> >>>>>> Não gosto de WebForms e não uso, mas existem casos onde não é viável
> >>>>>> usar outra coisa. Como disse o Tucaz outro dia: Tenho projetos que faturam
> >>>>>> milhões e não posso simplesmente mudar de tecnologia.
>
> >>>>>> E como eu disse em algumas palestras sobre MVC que dei: Talvez o único
> >>>>>> motivo aceitável para não usar MVC seja quando você já possui algo em
> >>>>>> WebForms.
>

> >>>>>> 2010/12/1 Henry Conceição <henry.concei...@gmail.com>

> >>>>>>> > > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> >>>>>>> <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> >>>>>>> > > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> >>>>>>> <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
>

> >>>>>>> > > > > > > Para mais opções visite o grupo em
> >>>>>>> > > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>>>>>> > > > > --
> >>>>>>> > > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> >>>>>>> <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>
> >>>>>>> > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> >>>>>>> <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> >>>>>>> > > > > Para mais opções visite o grupo em
>

> ...
>
> read more »

[Pedro Reys]

Oi Sidney, agora sim concordamos.

Claro que se você está em um projeto legado não dá pra sair reescrevendo tudo só pra estar aderente ao que hoje você entende como uma melhor escolha de design ou padrão. 

Meu ponto era justamente esse, a necessidade de usar SL normalmente vem de alguma restrição imposta pelo seu design.

A pouco tempo atrás trabalhei num projeto WinForms e num outro escrevi uma procedure com cursores. Nem sempre temos bons dias :)

Ah, e não podia ficar sem citar Fowler também.

[Vinicius Quaiato]

Eu diria que 15 dependências é algo demais...

Mas por exemplo, 3 dependências passadas no construtor para mim é um smell. No geral não são 3 dependências mandatórias, e mesmo assim passamos elas no construtor.

Se não é mandatória, e existe um setter para ela, ela está explícita, oras. Não é pq não está no construtor que não está explícita.

Dependências não explícita é aquela que é criada dentro da operação e não pode ser alterada, e ngm sabe que ela existe.

Eu não vou citar o Fowler :P

2010/12/2 Pedro Reys <pedr...@gmail.com>

[Thiago C. Santos]

Pedro, você mesmo disse que o SL é usado para solucionar uma restrição, ou seja, um problema! Este não é o objetivo dos Design Patterns? Acredito que nesta sua afirmação você mesmo reconheceu ele como sendo um Pattern.

Dizer que se deve usar somente DI e tachar SL como um "anti-pattern" acredito ser um equivoco.

Thiago C. Santos

2010/12/2 Vinicius Quaiato <vinicius...@gmail.com>

[Paulo Silveira - Caelum]

Oi pessoal

Vou dar meu pitaco baseado na minha experiencia com Java. Eu vou na
linha do Henry, e hoje ja nao considero SL uma forma de IoC.

O Vinicius fez um bom ponto: no final o container vai ficar com algum
tipo d SL interno. O service locator, assim como qualquer outro dos
patterns hoje considerados mais antipatterns (uso de static excessivo,
singletons e ate mesmo factories que agem mais como locators), vao
aparecer bem internamente, e é importante que eles estejam
escondidissimos e acessados por poucos. é por isso que delegamos essa
tarefa para dentro de um container, seja ele castle, ninject,
spring.net ou o que for.

Os containers antigos, como o spring, no comeco so permitiam setter
injection e recomendavam voce usar seu contexto/container como um
factory/locator. hoje em dia na documentacao podemos ver que a
recomendacao mudou drasticamente, e a injecao por construtor é de
longe a mais recomendada. é a base do principio do good citzen.

As especificacoes java tambem passaram por esse caminho: EJB 2 era
tudo por locators e factories (chamadas HOME), no EJB3 passou para
setter/atributo, e no ejb 3.1, junto com o CDI, finalmente foram para
o lado da injecao via construtor.

Mas, considerando ou nao SL uma forma de IoC (discussao que pode virar
bikeshedding), nao ha como compara-la em questao de acomplamento com
DI: DI da um grau de flexibilidade e desacoplamento _muito_ superior a
SL.

abracos

--
Paulo Silveira
Caelum | Ensino e Inovação
www.caelum.com.br

2010/12/1 Henry Conceição <henry.c...@gmail.com>:

[Vinicius Quaiato]

Para apimentar escrevi um texto sobre:

Nem só de constructor injection vive o IoC: http://viniciusquaiato.com/blog/nem-so-de-constructor-injection-vive-o-ioc/

2010/12/3 Paulo Silveira - Caelum <paulo.s...@caelum.com.br>

[Henry Conceição]

Vinicius,

Agora entendi pq vc defende SL como forma de IoC. Imho, o que vc chama
de IoC e na verdade o famigerado DI que o Martin Fowler inventou qdo
ao tentar entender IoC, olhou apenas os containers. O principio do IoC
é muito maior do q vc escreveu no seu post.

Aqui segue a melhor explicação sobre o conceito q eu ja vi:
http://www.betaversion.org/~stefano/linotype/news/38/

On Dec 3, 8:21 am, Vinicius Quaiato <vinicius.quai...@gmail.com>
wrote:

> Para apimentar escrevi um texto sobre:

> Nem só de constructor injection vive o IoC:http://viniciusquaiato.com/blog/nem-so-de-constructor-injection-vive-...
>
> 2010/12/3 Paulo Silveira - Caelum <paulo.silve...@caelum.com.br>

> > 2010/12/1 Henry Conceição <henry.concei...@gmail.com>:

> > >> > > > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
>
> > >> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
> > <dotnetarchitects%2525252Bu...@googlegroups.com<dotnetarchitects%252525252B...@googlegroups.com>
>

> > >> > > > > > > > Para mais opções visite o grupo em
> > >> > > > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > >> > > > > > --
> > >> > > > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>
> > >> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > >> > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > >> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
>
> > >> > > > > > Para mais opções visite o grupo em
> > >> > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > >> > > > > --

> > >> > > > > Kind regards,
> > >> > > > > *Juan Lopes *
>
> > >> > > > > *http://juanlopes.net*
>
> > >> > > > --
> > >> > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>

> > >> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > >> > > > Para mais opções visite o grupo em
>

> ...
>
> read more »

[Vinicius Quaiato]

Não!

Não entendo IoC como DI, e não caio naquele erro do link quebrado"(IoC 1, IoC 2 e IoC 3), mas existem formas de obter IoC.

Uma destas formas é DI (e DI sim tem essas 3 formas).

E pra mim SL é uma outra forma sim quando usado para atingir DI via setter.

2010/12/3 Henry Conceição <henry.c...@gmail.com>

[Pedro Reys]

Vinicius,

Você pode me mostrar um exemplo concreto onde usar SL ou Property Injection pra dependências não mandatórias seria uma boa?

Digo isso pois compartilho da opnião do Henry onde prefiro todas as dependências realmente explícitas no construtor. Prefiro que, uma vez instanciado, meu objeto esteja em um estado válido para realizar qualquer operação.

E não concordo que o fato de existir um Setter seja igualmente explícito a injetar essa dependência no construtor. O fato de haver um setter público me diz apenas que o objeto pode precisar daquela dependência, mas não torna explícito quando ele precisa. 

Uma coisa é o objeto requerer: "Olha, pra eu ser instanciado eu preciso das dependências A, B e C. Com essas dependências eu estou pronto pra ser usado e posso resolver qualquer uma das mensagens que receber".

Outra coisa é o objeto requerer: "Olha, pra eu ser instanciado eu preciso de A. Mas, quando/se você quiser, pode me passar B e C também." O problema dessa segunda opção, que a torna pior, IMO, é que agora cabe ao Caller saber que, antes de chamar foo.Bar() ele deve passar B. 

Eu entendi o que você está dizendo mas não estou conseguindo ver um exemplo concreto que corrobore o que você está dizendo. Talvez meu pensamento esteja biased em favor de constructor injection.

- Pedro Reys

2010/12/3 Vinicius Quaiato <vinicius...@gmail.com>

[Marcus Alexandre Silva]

Opinião de um leigo:

Porque ao invés de passar todos os objetos concretos no construtor voces não passam uma Func<SL>? Além de só carregar o que precisa na hora que ele for utilizado (aplicando um lazy por exemplo), a classe fica testavél e o objeto está em um estado válido da mesma forma.
Acho que este esquema de setter não fica muito bonito não.....

Marcus

[Giovanni Bassi]

O controle do tempo de vida não cabe às classes clientes, que usam o SL, ainda cabe ao conteiner. Fazer o contrário é assumir mais responsabilidades do que seria necessário.

Há uma dependência extra com SL, o que não é ideal. Viola mesmo o SRP. Mas não vou dizer que é errado ou gambiarra. O problema do webforms não é ele ser o webforms (esse é outro problema :)), o problema é que os webforms são criados pela infra do ASP.NET. Isso vai acontecer também com outros sistemas baseados em widgets, onde a infra cria o objeto. Por exemplo, você não pode injetar nada em um input text do html (DOM), porque é o browser quem cria ele. Mesma coisa com Silverlight, WPF, Windows Forms. Aí só cabe SL.

É um problema de quem cria, não se é webforms. Não adianta pegar ele como bode expiatório.

2010/12/1 Henry Conceição <henry.c...@gmail.com>

[Vinicius Quaiato]

Cara para qualquer dependência do tipo adjustment.

2010/12/3 Pedro Reys <pedr...@gmail.com>

[Giovanni Bassi]

Ah, e antes que alguém venha espernear que pode usar setter injection, eu também partilho da opinião que o objeto tem que estar consistente o tempo todo. Eu não quero ficar checando se um campo é nulo antes de usar. Ele tem que existir.

Se há um campo que não é usado nunca, senão em um método específico, de repente vale a pena usar outra abordagem. Talvez a responsabilidade esteja no lugar errado, talvez double dispatch, ou sei lá.

Mais uma vez: por outro lado, se eu precisar de setter injection eu vou usar. Essa história de que é anti padrão, e é gambiarra, e eu nunca vou usar me cansou. Pode ser que eu precise, e se eu precisar, eu não vou dar a volta ao mundo pra não usar. Produtividade sempre. Quando o custo de usar algo que pode não ser o ideal, como SL, não se pagar mais eu mudo. E como todo meu código tem testes, dane-se, é só mudar e apertar um botão.

2010/12/3 Giovanni Bassi <gig...@gmail.com>

[Juan Lopes]

Produtividade consciente FTW :)

2010/12/3 Giovanni Bassi <gig...@gmail.com>

[Vinicius Quaiato]

No geral dependências do tipo adjustments possuem valores default, e você pode alterá-las se convier, não existem checagens... 

Imagine como se fosse um "template method". Se alguém implementou ok, senão, ok também.

E uma dependência adjustment faz todo sentido ser usada com setter.

2010/12/3 Giovanni Bassi <gig...@gmail.com>

[Pedro Reys]

Bom, não acho que alguém defenda o "nunca vou usar". Como eu disse anteriormente, o uso de setter injection ou Service Locator normalmente se deve a uma restrição qualquer que seja imposta, normalmente por algum problema de design. 

Num passado recente, escrevi uma sproc num dia e tive de usar poor man D em outroI. Nem sempre temos dias legais :)

- Pedro Reys

2010/12/3 Giovanni Bassi <gig...@gmail.com>

[Pedro Reys]

1 exemplo concreto ... 

- Pedro Reys

2010/12/3 Vinicius Quaiato <vinicius...@gmail.com>

No geral dependências do tipo adjustments possuem valores default, e você pode alterá-las se convier, não existem checagens... 

[Vinicius Quaiato]

Cara acabei de citar isso no meu blog.

Você tem um processo de venda. E sei lá, um cálculo de desconto, imposto, taxa, diferenciado do padrão. Ele não é obrigatório, e você só fica sabendo dele após o objeto de venda ter sido criado, mas antes de finalizado.

É uma dependências do tipo adjustment. Simples assim.

Como vou passar esse cara no construtor?

Qualquer sistema de vendas vai se deparar com casos desse tipo.

2010/12/3 Pedro Reys <pedr...@gmail.com>

[Giovanni Bassi]

Nao fica mais fácil trabalhar delegando a responsabilidade?

venda.Descontar(politica);

2010/12/3 Vinicius Quaiato <vinicius...@gmail.com>

[Vinicius Quaiato]

De qualquer forma você pode usar o SL para obter a política. Ou sei lá, uma fábrica, etc.

De qualquer forma você tirou essa dependência do construtor.

Mas se essa política vai ser utilizada em mais de um método a partir desse momento, faz sentido o setter, ou um "ConfigurarPolitica". O que dá na mesma.

2010/12/4 Giovanni Bassi <gig...@giggio.net>

[Juan Lopes]

Acabei de ver um exemplo que pode dar força ao argumento de dependency injection por getter e setter.

Não sei se vocês estão acompanhando o framework Nancy, mas eu estava dando uma olhada no código. Vejam essa classe:

https://github.com/thecodejunkie/Nancy/blob/master/src/Nancy/NancyModule.cs

Ela precisa que as dependências para IRequest, IViewEngine e IReponseFormatter sejam injetadas nela. Entretanto, ela é uma classe abstrata, parte da API pública do framework. Não me parece razoável exigir esses componentes via construtor, obrigando a quem herdar dessa classe a implementar um construtor que receba essas interfaces. 

Vocês vêem alguma alternativa que não torne a API mais complexa?

2010/12/4 Vinicius Quaiato <vinicius...@gmail.com>

--

[Giovanni Bassi]

Oras, não entendi... Se as dependências são obrigatórias, isso deve ser informado via construtor, de forma a deixar essa informação mais explícita. Não vai ficar mais complexo, vai ficar menos.

2010/12/4 Juan Lopes <juanp...@gmail.com>

[Juan Lopes]

Você realmente prefere na hora de criar uma classe que herda de NancyModule, escrever um construtor que recebe três interfaces que você não sabe pra que servem e só passar pra frente? Acho feio. Assim como quando hero de Exception ser obrigado a escrever um construtor que receber SerializationInfo e StreamingContext

2010/12/5 Giovanni Bassi <gig...@giggio.net>

[Vinicius Quaiato]

Se não é obrigatória, tire do construtor... ou use construtores sobrecarregados.

Easy.

2010/12/5 Juan Lopes <juanp...@gmail.com>

[Juan Lopes]

Vinicius, não é esse o problema.

Imagine se você, ao criar um controller, fosse obrigado a criar um construtor que recebesse RouteData e ControllerContext? Mesmo sendo obrigatórios, o ASP.NET MVC os injeta no seu controller por getter e setter, porque injeção por construtor nesse caso é ridícula.

2010/12/5 Vinicius Quaiato <vinicius...@gmail.com>

[Vinicius Quaiato]

Além disso :P

2010/12/5 Juan Lopes <juanp...@gmail.com>

[Henry Conceição]

Vc volta ao problema de nunca saber em qual momento o objeto esta
ready ou nao. Imagino eu q nao é possivel acessar nenhum desses
services no constructor, pois as dependencias nao obrigatorias so são
resolvidas depois da construção do objeto. E como side effect, vc
precisa criar um Init method ou coisa semelhante para que os
implementors tenham algum lugar onde customizar a inicialização do
serviço.

Mas isso nao é tanto um problema de IoC, e sim do design do framework
privilegiar inheritance ao inves de composition.

On Dec 5, 10:51 pm, Juan Lopes <juanplo...@gmail.com> wrote:
> Vinicius, não é esse o problema.
>
> Imagine se você, ao criar um controller, fosse obrigado a criar um
> construtor que recebesse RouteData e ControllerContext? Mesmo sendo
> obrigatórios, o ASP.NET MVC os injeta no seu controller por getter e setter,
> porque injeção por construtor nesse caso é ridícula.
>

> 2010/12/5 Vinicius Quaiato <vinicius.quai...@gmail.com>

>
> > Se não é obrigatória, tire do construtor... ou use construtores
> > sobrecarregados.
> > Easy.
>

> > 2010/12/5 Juan Lopes <juanplo...@gmail.com>

>
> >> Você realmente prefere na hora de criar uma classe que herda de
> >> NancyModule, escrever um construtor que recebe três interfaces que você não
> >> sabe pra que servem e só passar pra frente? Acho feio. Assim como quando
> >> hero de Exception ser obrigado a escrever um construtor que receber
> >> SerializationInfo e StreamingContext
>
> >> 2010/12/5 Giovanni Bassi <gig...@giggio.net>
>
> >> Oras, não entendi... Se as dependências são obrigatórias, isso deve ser
> >>> informado via construtor, de forma a deixar essa informação mais explícita.
> >>> Não vai ficar mais complexo, vai ficar menos.
>

> >>> 2010/12/4 Juan Lopes <juanplo...@gmail.com>

>
> >>>>  Acabei de ver um exemplo que pode dar força ao argumento de dependency
> >>>> injection por getter e setter.
>
> >>>> Não sei se vocês estão acompanhando o framework Nancy, mas eu estava
> >>>> dando uma olhada no código. Vejam essa classe:
>

> >>>>https://github.com/thecodejunkie/Nancy/blob/master/src/Nancy/NancyMod...

>
> >>>> Ela precisa que as dependências para IRequest, IViewEngine e
> >>>> IReponseFormatter sejam injetadas nela. Entretanto, ela é uma classe
> >>>> abstrata, parte da API pública do framework. Não me parece razoável exigir

> >>>> esses componentes via construtor, *obrigando a quem herdar dessa classe
> >>>> a implementar um construtor que receba essas interfaces*.

>
> >>>> Vocês vêem alguma alternativa que não torne a API mais complexa?
>

> >>>> 2010/12/4 Vinicius Quaiato <vinicius.quai...@gmail.com>

>
> >>>> De qualquer forma você pode usar o SL para obter a política. Ou sei lá,
> >>>>> uma fábrica, etc.
> >>>>> De qualquer forma você tirou essa dependência do construtor.
>
> >>>>> Mas se essa política vai ser utilizada em mais de um método a partir
> >>>>> desse momento, faz sentido o setter, ou um "ConfigurarPolitica". O que dá na
> >>>>> mesma.
>
> >>>>> 2010/12/4 Giovanni Bassi <gig...@giggio.net>
>
> >>>>> Nao fica mais fácil trabalhar delegando a responsabilidade?
> >>>>>> venda.Descontar(politica);
>

> >>>>>> 2010/12/3 Vinicius Quaiato <vinicius.quai...@gmail.com>

>
> >>>>>>> Cara acabei de citar isso no meu blog.
>
> >>>>>>> Você tem um processo de venda. E sei lá, um cálculo de desconto,
> >>>>>>> imposto, taxa, diferenciado do padrão. Ele não é obrigatório, e você só fica
> >>>>>>> sabendo dele após o objeto de venda ter sido criado, mas antes de
> >>>>>>> finalizado.
> >>>>>>> É uma dependências do tipo adjustment. Simples assim.
>
> >>>>>>> Como vou passar esse cara no construtor?
>
> >>>>>>> Qualquer sistema de vendas vai se deparar com casos desse tipo.
>

> >>>>>>> 2010/12/3 Pedro Reys <pedror...@gmail.com>

>
> >>>>>>>> 1 exemplo concreto ...
>
> >>>>>>>> - Pedro Reys
>

> >>>>>>>> 2010/12/3 Vinicius Quaiato <vinicius.quai...@gmail.com>

> >>>>>>>>>>> 2010/12/1 Henry Conceição <henry.concei...@gmail.com>

> ...
>
> read more »

[Vinicius Quaiato]

A não ser que você use alguma forma de DbC, lógica no construtor não é algo interessante.

2010/12/6 Henry Conceição <henry.c...@gmail.com>

> ...
>
> read more »

[Giovanni Bassi]

Exatamente, quando o objeto está disponível para uso? E usar init é um negócio bem ruim se isso não ficar claro como deve ser usado.

Juan, no caso, o Controller não recebe nenhum parâmetro no construtor porque os parâmetros são passados aos métodos. Quando a Infra do ASP.NET MVC chama o controller, passa o requestContext, que seta todas os campos, como o Request, Response, etc, etc... Se você verificar, no construtor nada disso está setado. Isso só prova que a dependência não é obrigatória, ou seja, exatamente o que eu estava dizendo. Usar o exemplo do controller só confirma o que eu disse. O design é diferente do que eu propus, e parecido com o que eu havia proposto antes ao Vinicius: passe no método os objetos que ele vai precisar.

Pra entender melhor é só dar uma olhada em ControllerBase.Execute, que é a implementação do único método de IController.

Só pra fechar: o uso de um método de inicialização (vários, na verdade) no ASP.NET MVC faz sentido porque o único ponto de entrada de um controller é pelo Execute(RequestContext), que depois vai chamar as ações. Nesse cenário, exigir parâmetros nos construtores seria desnecessário, já que o RequestContext na prática atua como um Registry e por isso tem como informar todas as dependências.

Por fim: Henry, onde está a preferência de herança sobre composição? Pode ser mais claro?

[]s

> ...
>
> read more »

[Vinicius Quaiato]

Passar no método não é muito diferente do que eu estava propondo, afinal um setter nada mais é do que um método.

O grande ponto é: tirar isso do construtor quando não deve estar lá. Construtor não é o único ponto para IoC e DI.

É o mais comum, e talvez o mais simples de "sair usando", mas como você mesmo gosta de dizer Giovanni: "fazer software não é simples". Às vezes vai requerer um maior entendimento e melhores habilidades de design.

Isso me faz pensar também em "last responsible moment" para passar a dependência.

Abraços,

Vinicius Quaiato.

2010/12/6 Giovanni Bassi <gig...@giggio.net>

[Lucas]

Não li todas as repostas do post mas acho q esse link pode ajudar!

Is MEF a next dependency injection container? – My vote: NO
http://gorskib.wordpress.com/2010/12/04/is-mef-a-next-dependency-injection-container-%E2%80%93-my-vote-no/

On Nov 30, 2:06 pm, "Thiago C. Santos" <thiago.csantos...@gmail.com>
wrote:

[Henry Conceição]

Tudo gira em torno da classe Controller. Até existe uma interface la
no fundo definindo o contrato, mas no real world, raramente os
desenvolvedores topam a tarefa de implementar o seu. Entao, vc acaba
"obrigando" todos os usuários do framework a herdarem da classe x ou y
para ter acesso a um set de serviços.

On Dec 6, 1:37 am, Giovanni Bassi <gig...@giggio.net> wrote:
> Exatamente, quando o objeto está disponível para uso? E usar init é um
> negócio bem ruim se isso não ficar claro como deve ser usado.
>
> Juan, no caso, o Controller não recebe nenhum parâmetro no construtor porque
> os parâmetros são passados aos métodos. Quando a Infra do ASP.NET MVC chama
> o controller, passa o requestContext, que seta todas os campos, como o
> Request, Response, etc, etc... Se você verificar, no construtor nada disso
> está setado. Isso só prova que a dependência não é obrigatória, ou seja,
> exatamente o que eu estava dizendo. Usar o exemplo do controller só confirma
> o que eu disse. O design é diferente do que eu propus, e parecido com o que
> eu havia proposto antes ao Vinicius: passe no método os objetos que ele vai
> precisar.
> Pra entender melhor é só dar uma olhada em ControllerBase.Execute, que é a
> implementação do único método de IController.
> Só pra fechar: o uso de um método de inicialização (vários, na verdade) no
> ASP.NET MVC faz sentido porque o único ponto de entrada de um controller é
> pelo Execute(RequestContext), que depois vai chamar as ações. Nesse cenário,
> exigir parâmetros nos construtores seria desnecessário, já que o
> RequestContext na prática atua como um Registry e por isso tem como informar
> todas as dependências.
>
> Por fim: Henry, onde está a preferência de herança sobre composição? Pode
> ser mais claro?
>
> []s
>
> On Mon, Dec 6, 2010 at 12:27 AM, Henry Conceição

> <henry.concei...@gmail.com>wrote:

> ...
>
> read more »

[Henry Conceição]

Uma pessoa q define o Windsor ou Unity como DI container muito
provavelmente nao entedeu o principio do IoC. Logo, imo, ele nao tem
base suficiente para cravar o q é ou nao é um container.

Este post aqui explica melhor o posicionamento do mef:
http://blogs.msdn.com/b/hammett/archive/2010/05/29/mef-what-and-why.aspx

On Dec 6, 11:15 am, Lucas <lucassimoesmais...@gmail.com> wrote:
> Não li todas as repostas do post mas acho q esse link pode ajudar!
>

> Is MEF a next dependency injection container? – My vote: NOhttp://gorskib.wordpress.com/2010/12/04/is-mef-a-next-dependency-inje...

[Vinicius Quaiato]

Henry, na boa?

Posso usar IoC até com o "ContainerDaVovó" se eu quiser.

Se atingi o objetivo, pronto!

Solução simples que atende. 

Agora se isso está na sua definição canônica papa blessed de IoC, são outros 500.

2010/12/6 Henry Conceição <henry.c...@gmail.com>

[Thiago C. Santos]

Só falta dizer que spring também não serve...

Thiago C. Santos

2010/12/6 Vinicius Quaiato <vinicius...@gmail.com>

[Henry Conceição]

Vinicius,

O q eu quis dizer é q o unity e o windsor sao IoC containers, e nao DI
containers.

Se pra vc tudo é a mesma coisa ou se esses conceitos sao maleaveis,
melhor pararmos a discussão por aqui pq nao vai levar a lugar nenhum.

On Dec 6, 11:56 am, Vinicius Quaiato <vinicius.quai...@gmail.com>
wrote:

> Henry, na boa?
>
> Posso usar IoC até com o "ContainerDaVovó" se eu quiser.
> Se atingi o objetivo, pronto!
>
> Solução simples que atende.
>
> Agora se isso está na sua definição canônica papa blessed de IoC, são outros
> 500.
>

> 2010/12/6 Henry Conceição <henry.concei...@gmail.com>

>
> > Uma pessoa q define o Windsor ou Unity como DI container muito
> > provavelmente nao entedeu o principio do IoC. Logo, imo, ele nao tem
> > base suficiente para cravar o q é ou nao é um container.
>
> > Este post aqui explica melhor o posicionamento do mef:
> >http://blogs.msdn.com/b/hammett/archive/2010/05/29/mef-what-and-why.aspx
>
> > On Dec 6, 11:15 am, Lucas <lucassimoesmais...@gmail.com> wrote:
> > > Não li todas as repostas do post mas acho q esse link pode ajudar!
>
> > > Is MEF a next dependency injection container? – My vote: NOhttp://
> > gorskib.wordpress.com/2010/12/04/is-mef-a-next-dependency-inje...
>
> > > On Nov 30, 2:06 pm, "Thiago C. Santos" <thiago.csantos...@gmail.com>
> > > wrote:
>
> > > > Vi uma discussão aqui sobre o MEF, e pergunto... é incorreto usar o MEF
> > como
> > > > um Ioc/DI?
>
> > > > Thiago C. Santos
>
> > --
> > 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<dotnetarchitects%2Bunsu...@googlegroups.com>

[Vinicius Quaiato]

A questão é: Se você pode utilizá-los para DI, que seja. Se isso está sendo simples e ajudando, pronto.

Essa idéia de "as coisas são assim e pronto" é coisa do passado.

90% das pessoas usam containers de IoC para DI, e qual o problema nisso? Relaxa!

2010/12/6 Henry Conceição <henry.c...@gmail.com>

[Thiago Alves]

Henry,

A noção que eu tinha até agora é que tanto DI quanto SL seriam formas diferentes de alcançar inversão de controle (IoC), sendo que DI é uma forma mais "elegante", já que no caso de SL uma classe 

2010/12/3 Henry Conceição <henry.c...@gmail.com>

Vinicius,

Agora entendi pq vc defende SL como forma de IoC. Imho, o que vc chama
de IoC e na verdade o famigerado DI que o Martin Fowler inventou qdo
ao tentar entender IoC, olhou apenas os containers. O principio do IoC
é muito maior do q vc escreveu no seu post.

Aqui segue a melhor explicação sobre o conceito q eu ja vi:
http://www.betaversion.org/~stefano/linotype/news/38/

On Dec 3, 8:21 am, Vinicius Quaiato <vinicius.quai...@gmail.com>
wrote:

> Para apimentar escrevi um texto sobre:

> Nem só de constructor injection vive o IoC:http://viniciusquaiato.com/blog/nem-so-de-constructor-injection-vive-...
>
> 2010/12/3 Paulo Silveira - Caelum <paulo.silve...@caelum.com.br>

>
> > Oi pessoal
>
> > Vou dar meu pitaco baseado na minha experiencia com Java. Eu vou na
> > linha do Henry, e hoje ja nao considero SL uma forma de IoC.
>
> > O Vinicius fez um bom ponto: no final o container vai ficar com algum
> > tipo d SL interno. O service locator, assim como qualquer outro dos
> > patterns hoje considerados mais antipatterns (uso de static excessivo,
> > singletons e ate mesmo factories que agem mais como locators), vao
> > aparecer bem internamente, e é importante que eles estejam
> > escondidissimos e acessados por poucos. é por isso que delegamos essa
> > tarefa para dentro de um container, seja ele castle, ninject,
> > spring.net ou o que for.
>
> > Os containers antigos, como o spring, no comeco so permitiam setter
> > injection e recomendavam voce usar seu contexto/container como um
> > factory/locator. hoje em dia na documentacao podemos ver que a
> > recomendacao mudou drasticamente, e a injecao por construtor é de
> > longe a mais recomendada. é a base do principio do good citzen.
>
> > As especificacoes java tambem passaram por esse caminho: EJB 2 era
> > tudo por locators e factories (chamadas HOME), no EJB3 passou para
> > setter/atributo, e no ejb 3.1, junto com o CDI, finalmente foram para
> > o lado da injecao via construtor.
>
> > Mas, considerando ou nao SL uma forma de IoC (discussao que pode virar
> > bikeshedding), nao ha como compara-la em questao de acomplamento com
> > DI: DI da um grau de flexibilidade e desacoplamento _muito_ superior a
> > SL.
>
> > abracos
>
> > --
> > Paulo Silveira
> > Caelum | Ensino e Inovação
> >www.caelum.com.br
>

> > 2010/12/1 Henry Conceição <henry.concei...@gmail.com>:

> > > Entendo a situaçao, mas isso imo nao muda o status do SL como sendo um
> > > falha de design e/ou anti-pattern. É usar uma gambiarra (SL) pra
> > > amenizar outra (WebForms).
>
> > > On Dec 1, 3:19 pm, Vinicius Quaiato <vinicius.quai...@gmail.com>
> > > wrote:
> > >> Nem tudo é tão simples. Se você já tem aplicações e precisa manter, não
> > >> existe mágica cara.
> > >> Nem sempre dá pra migrar, e nesses casos SL é uma solução sim.
>
> > >> Não gosto de WebForms e não uso, mas existem casos onde não é viável
> > usar
> > >> outra coisa. Como disse o Tucaz outro dia: Tenho projetos que faturam
> > >> milhões e não posso simplesmente mudar de tecnologia.
>
> > >> E como eu disse em algumas palestras sobre MVC que dei: Talvez o único

> > >> motivo aceitável para não usar MVC seja quando você já possui algo em
> > >> WebForms.
>
> > >> 2010/12/1 Henry Conceição <henry.concei...@gmail.com>
>
> > >> > Sim, eu sei que IoC e Di sao diferentes.
>
> > >> > E infeliz é quem usa WebForms e precisa estuprar o design e violar
> > >> > estes principios. E alem disso, so prova o meu ponto q se vc precisar
> > >> > de ServiceLocator, vc falhou. Seja na escolha de algum framework (ex:
> > >> > WebForms) ou no seu design.
>

> > >> > On Dec 1, 3:02 pm, Vinicius Quaiato <vinicius.quai...@gmail.com>

> > >> > > > > > On Nov 30, 4:54 pm, "Thiago C. Santos" <
> > >> > thiago.csantos...@gmail.com>

> > >> > > > > > wrote:
> > >> > > > > > > Então, o Unity esta me interessando bastante!
>
> > >> > > > > > > Estou implementando com Ioc/Service Locator.
>
> > >> > > > > > > Thiago C. Santos
>
> > >> > > > > > > 2010/11/30 Lucas <lucassimoesmais...@gmail.com>
>
> > >> > > > > > > > Cara não sei se é incorreto, mas estou usando e funciona
> > bem.
> > >> > > > Existe o
> > >> > > > > > > > Unity tb, porém não tenho experiência com ele.
>
> > >> > > > > > > > abs
>
> > >> > > > > > > > lucas
>

> > >> > > > > > > > On 30 nov, 14:06, "Thiago C. Santos" <

> > >> > thiago.csantos...@gmail.com>
> > >> > > > > > > > wrote:
> > >> > > > > > > > > Vi uma discussão aqui sobre o MEF, e pergunto... é
> > incorreto
> > >> > usar
> > >> > > > o
> > >> > > > > > MEF
> > >> > > > > > > > como
> > >> > > > > > > > > um Ioc/DI?
>
> > >> > > > > > > > > Thiago C. Santos
>
> > >> > > > > > > > --
> > >> > > > > > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>

> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>
> > >> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > >> > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > >> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
>
> > >> > > > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > >> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
>
> > >> > > > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
>
> > >> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>

> > <dotnetarchitects%2525252Bu...@googlegroups.com<dotnetarchitects%252525252B...@googlegroups.com>

>

> > >> > > > > > > > Para mais opções visite o grupo em
> > >> > > > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > >> > > > > > --
> > >> > > > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>
> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>
> > >> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > >> > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>
> > >> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
> > <dotnetarchitects%25252Bun...@googlegroups.com<dotnetarchitects%2525252Bu...@googlegroups.com>
>

> > >> > > > > > Para mais opções visite o grupo em
> > >> > > > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > >> > > > > --

> > >> > > > > Kind regards,
> > >> > > > > *Juan Lopes *
>
> > >> > > > > *http://juanlopes.net*

>
> > >> > > > --
> > >> > > > 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<dotnetarchitects%2Bunsu...@googlegroups.com>

> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
>

> > >> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@googlegroups.com>
>

> > >> > > > Para mais opções visite o grupo em
>

> ...
>
> read more »

[Thiago Alves]

(essas teclas de atalho do gmail... tsc, tsc)

Henry,

A noção que eu tinha até agora é que tanto DI quanto SL seriam formas diferentes de alcançar inversão de controle (IoC), sendo que DI é uma forma mais "elegante", já que no caso de SL é criada uma dependência entre a classe consumidora e uma factory ou Service Locator, sendo que o objetivo de IoC é aumentar isolamento e reuso. É isso mesmo? Qual é a parte que eu não entendi? Agora fiquei confuso.

Abraço,

Thiago Alves

2010/12/7 Thiago Alves <thiag...@gmail.com>

[Henry Conceição]

Eu considero SL fere mortalmente o principio do IoC pq vc conhece
detalhadamente o SL. Ele acaba fazendo o mesmo papel de um factory ou
coisa do genero, leakando a responsabilidade de resolver a instancia e
cuidar de parte do lifetime para o consumer.

DI é so mais um buzzword criado pelo Martin Fowler. Vc esperar
parametros no constructor ou expor properties em sua classes nao quer
dizer nada. É totalmente misleading esse "pattern".

On Dec 7, 11:33 am, Thiago Alves <thiago1...@gmail.com> wrote:
> (essas teclas de atalho do gmail... tsc, tsc)
>
> Henry,
>
> A noção que eu tinha até agora é que tanto DI quanto SL seriam formas
> diferentes de alcançar inversão de controle (IoC), sendo que DI é uma forma
> mais "elegante", já que no caso de SL é criada uma dependência entre a
> classe consumidora e uma factory ou Service Locator, sendo que o objetivo de
> IoC é aumentar isolamento e reuso. É isso mesmo? Qual é a parte que eu não
> entendi? Agora fiquei confuso.
>
> Abraço,
> Thiago Alves
>

> 2010/12/7 Thiago Alves <thiago1...@gmail.com>

>
> > Henry,
>
> > A noção que eu tinha até agora é que tanto DI quanto SL seriam formas
> > diferentes de alcançar inversão de controle (IoC), sendo que DI é uma forma
> > mais "elegante", já que no caso de SL uma classe
>

> > 2010/12/3 Henry Conceição <henry.concei...@gmail.com>

> ...
>
> read more »

[Juan Lopes]

Então, Henry, não diga o que não é IoC e tente dizer o que é.

2010/12/7 Henry Conceição <henry.c...@gmail.com>

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--

Kind regards,
Juan Lopes 

http://juanlopes.net

[Thiago C. Santos]

Henry...

Independente de você não considerar ele como uma implementação de IoC (eu considero), ele faz o mesmo que você pretende fazer com DI, que é o desacoplamento das camadas. Isso é algo INCONTESTÁVEL!!! você ganha o acoplamento com a camada do SL mas você atinge o desacoplamento de todas as outras camadas.

E sobre o controle do lifetime... nem todo sistema é de telas simples de CRUD e de implementações comuns, isso pode proporcionar dinamismo no seu código, vai da criatividade e capacidade de quem esta utilizando.

Na minha opinião, se possível utilizar DI é preferível optar por ele, mas se SL pode lhe propor uma solução viável para o que você esteja fazendo ou ate mesmo DI não estar lhe servindo, não tem cabimento mudar tudo para usar DI, SL é um pattern!!

Thiago C. Santos

2010/12/7 Juan Lopes <juanp...@gmail.com>

[Henry Conceição]

Nao é o seu código que está no comando da execução. Ele esta sendo
executado por um framework/api/host.

E qdo vc usa um SL, vc assume o controle.


On Dec 7, 12:37 pm, Juan Lopes <juanplo...@gmail.com> wrote:
> Então, Henry, não diga *o que não é* IoC e tente dizer *o que é*.
>
> 2010/12/7 Henry Conceição <henry.concei...@gmail.com>

> ...
>
> read more »

[Thiago C. Santos]

???

SL: Você pede explicitamente para o SL o que você quer.

DI: Não há pedido explicito no seu código, mas é atribuído a ele o que ele necessita.

Dizer que o seu código não esta no comando fica confuso, com DI ele simplesmente não sabe suas dependências e nem de onde vem, mas obviamente ele esta no controle, somente não esta no controle no contexto das dependências.

Mas as duas fazem o desacoplamento das camadas.

Thiago C. Santos

2010/12/7 Henry Conceição <henry.c...@gmail.com>

[Thiago Alves]

Henry, deixa eu ver se entendi o que você quis dizer:

Quando você usa um framework, é ele que controla a execução, e "consome" seu código, e quando você usa uma biblioteca, quem tem o controle é o seu código, e ele consome a biblioteca.

A ideia do IoC é aumentar o reuso transferindo o comando da execução para um container. E ao usar a técnica que o Martin Fowler chama de Dependency Injection, você não necessariamente está usando inversão de controle, já que nada impede que comando da execução continue em um dos dois módulos envolvidos na dependência.

Entendi certo seu raciocínio?

2010/12/7 Henry Conceição <henry.c...@gmail.com>

[Vinicius Quaiato]

No fundo é tudo a mesma coisa.

A diferença é que o que vc está dizendo não está no seu controle. Mas no fundo inverte o controle da mesma forma.

A questão não é 'você' não estar no controle, mas o objeto alvo não estar.

2010/12/7 Henry Conceição <henry.c...@gmail.com>

[Giovanni Bassi]

Peraí, Henry. IoC é inversion of control. É um padrão bem definido. E com SL dá pra implementar o padrão numa boa. Há uma dependência a um Registry (SL), mas ainda assim o controle foi invertido, e isso é inegável.

[Henry Conceição]

Na sua opinião.

On Dec 8, 5:11 am, Giovanni Bassi <gig...@giggio.net> wrote:
> Peraí, Henry. IoC é inversion of control. É um padrão bem definido. E com SL
> dá pra implementar o padrão numa boa. Há uma dependência a um Registry (SL),
> mas ainda assim o controle foi invertido, e isso é inegável.
>
> On Tue, Dec 7, 2010 at 6:34 AM, Henry Conceição

> <henry.concei...@gmail.com>wrote:

> ...
>
> read more »

[Sidney Lima Filho]

Henry, qual é a sua opinião sobre IoC? Atenciosamente Sidney Lima Filho  Vivina Softhouse (0xx21) 7867-2321 55*10*68934 BLOG: http://blog.vivina.com.br   |    http://twitter.com/vivina

2010/12/8 Henry Conceição <henry.c...@gmail.com>

[Vinicius Quaiato]

Não Henry, na opinião do mercado!

Só vc e esse "seu amigo" pensam diferente disso pelo visto.

2010/12/8 Henry Conceição <henry.c...@gmail.com>

[Cadu]

deve ser o amigo imaginário dele aheuaheuae tive q zuar não resisti!!!!!!!!!!!!

--

Twitter: @cadu_sza

Blog: http://architecturelife.wordpress.com/

[Henry Conceição]

Puxa, muito zueiro esse Cadu e o Vinicius. Vou ficar sem dormir depois
da manifestação de pessoas tão relevantes.

Alias, vcs deveriam escrever um blog post sobre isto, e fazer o plug
aqui para o resto da turma bater palminha.

On Dec 8, 1:10 pm, Cadu <cadus...@gmail.com> wrote:
> deve ser o amigo imaginário dele aheuaheuae tive q zuar não
> resisti!!!!!!!!!!!!
>

> Em 8 de dezembro de 2010 06:35, Vinicius Quaiato <vinicius.quai...@gmail.com

>
> > escreveu:
> > Não Henry, na opinião do mercado!
>
> > Só vc e esse "seu amigo" pensam diferente disso pelo visto.
>

> > 2010/12/8 Henry Conceição <henry.concei...@gmail.com>

> ...
>
> read more »

[Henry Conceição]

Por "resto da turma" nao quis generalizar o grupo inteiro. Era
direcionado aos dois palhaçinhos que nao conseguem segurar o nivel da
discussão sem descambar pro pessoal.

Sorry se passei a impressao errada.

> ...
>
> read more »

[Sidney Lima Filho]

Henry, já que não me enquadro no resto da turma, explique melhor por favor porque você disse "Na sua opinião." ao argumento do Giovanni. Pois o que ele falou é plausivel e gostaria de entender sua opinião plausivel também.

Atenciosamente Sidney Lima Filho  Vivina Softhouse (0xx21) 7867-2321 55*10*68934 BLOG: http://blog.vivina.com.br   |    http://twitter.com/vivina

2010/12/8 Henry Conceição <henry.c...@gmail.com>

Por "resto da turma" nao quis generalizar o grupo inteiro. Era

> ...
>
> read more »

[Giovanni Bassi]

Oi Henry,

Ok, se quiser chamar de opinião, desde que entenda que é a opinião do resto do mundo também, com poucas exceções (você e mais um ou outro que eu não conheço).

Na prática, IoC é um princípio muito maior do que o que o que estamos dizendo e pode sim ser aplicado com SL. Pra entender melhor:

http://en.wikipedia.org/wiki/Inversion_of_control

A inversão de dependência é um caso especial do IoC, que pode se aplicar a frameworks, e outras coisas. Isso não muda o fato de que SL pode ser usado para atingir DI, e portando IoC.

O interessante é que o Uncle Bob concorda:

http://www.objectmentor.com/resources/articles/dip.pdf

E é interessante notar que muito se fala de IoC por causa do SOLID do Uncle Bob, onde o D é Dependency Inversion.

Eu poderia puxar inumeras outras referências para confirmar o que estou dizendo. É assim que o mercado entende DI e IoC. O conceito não é definido pelo que você acha que ele é Henry, mas como as pessoas entendem que ele funciona. É essa concordância social que dá a ele relevância. Isso vale para qualquer ideia.

Eu vi como vocês do Castle entendem IoC (http://www.castleproject.org/container/documentation/v1rc3/concepts/ioc.html) e é interessante notar que a página em questão já trabalha enviesada, expondo a mesma ideia que você está dizendo, esquecendo que o mundo pensa diferente.

[]s

Giovanni Bassi

[Vinicius Quaiato]

Henry na boa, você entendeu bem o que eu disse. 

A referência foi ao post que vc mandou sobre "a melhor definição de IoC que eu já vi no mundo".

Se você deu margem para as piadas subsequentes isso é outro problema.

Estamos há posts dizendo que sua opinião não condiz com o mercado, e você sempre se limitando a dizer: "isso não é IoC".

Então man, relax.

O mercado modelou o conceito tal qual como é hoje, e você precisa aceitar isso.

2010/12/8 Henry Conceição <henry.c...@gmail.com>

> ...
>
> read more »

[Henry Conceição]

Giovanni,

Alguns pontos:

1 - O Uncle Bob fala sobre dependency inversion apenas (nao li o
artigo inteiro). Nao achei onde ele iguala IoC e DI.
2 - Sim, minha visão, é enviesada e conservadora. Uma vez que não fui
apresentado ao assunto pelo Martin Fowler e nao acho q a redefinição
dele faz sentido e/ou seja correta.
3 - A ideia da aceitação pela maioria do mercado, imo, é uma falacia.
Ele é capaz de distorcer e corromper ideias. IoC = DI e apenas mais um
caso.
4 - Em nenhum momento eu disse que SL nao uma ferramenta para se obter
DI, e sim IoC. E so para registrar, IoC != DI.

On Dec 8, 1:40 pm, Giovanni Bassi <gig...@giggio.net> wrote:
> Oi Henry,
>
> Ok, se quiser chamar de opinião, desde que entenda que é a opinião do resto
> do mundo também, com poucas exceções (você e mais um ou outro que eu não
> conheço).
>
> Na prática, IoC é um princípio muito maior do que o que o que estamos
> dizendo e pode sim ser aplicado com SL. Pra entender melhor:http://en.wikipedia.org/wiki/Inversion_of_control
> <http://en.wikipedia.org/wiki/Inversion_of_control>A inversão de dependência
> é um caso especial do IoC, que pode se aplicar a frameworks, e outras
> coisas. Isso não muda o fato de que SL pode ser usado para atingir DI, e
> portando IoC.
> O interessante é que o Uncle Bob concorda:http://www.objectmentor.com/resources/articles/dip.pdf
> E é interessante notar que muito se fala de IoC por causa do SOLID do Uncle
> Bob, onde o D é Dependency Inversion.
>
> Eu poderia puxar inumeras outras referências para confirmar o que estou
> dizendo. É assim que o mercado entende DI e IoC. O conceito não é definido
> pelo que você acha que ele é Henry, mas como as pessoas entendem que ele
> funciona. É essa concordância social que dá a ele relevância. Isso vale para
> qualquer ideia.
>

> Eu vi como vocês do Castle entendem IoC (http://www.castleproject.org/container/documentation/v1rc3/concepts/i...)

> e é interessante notar que a página em questão já trabalha enviesada,
> expondo a mesma ideia que você está dizendo, esquecendo que o mundo pensa
> diferente.
>
> []s
>
> Giovanni Bassi

> <http://www.objectmentor.com/resources/articles/dip.pdf>

>
> On Wed, Dec 8, 2010 at 5:48 AM, Henry Conceição

> <henry.concei...@gmail.com>wrote:

> ...
>
> read more »

[Thiago C. Santos]

Que paradoxo...

Ninguém disse (IoC = DI), apenas que se atinge a inversão de controle com o DI ou com SL.

Thiago C. Santos

2010/12/8 Henry Conceição <henry.c...@gmail.com>

> ...
>
> read more »

[Giovanni Bassi]

Cansei.

Henry, eu não disse que são iguais. Le o que eu escrevi e você vai entender.

2010/12/8 Henry Conceição <henry.c...@gmail.com>

> ...
>
> read more »

[Pedro Reys]

Bom,

Primeiro com relação a: "É o que o mercado aceita/diz/define". Isso é uma falácia, Argumentum ad Populum, e vocês sabem disso. Aliás, é essa mesma falácia usada por pessoas que defendem Waterfall, PMI e outras coisas que tentamos mudar a maneira que o mercado entende, não é mesmo?

Voltando ao assunto da thread: É de fato confusa a distinção de termos entre IoC, Dependency Injection, Dependency Inversion. Neste link aqui há um texto que dá uma explicação temporal para isso: http://www.picocontainer.org/inversion-of-control-history.html

O texto do Bob Martin é de 1994, o termo Inversion of Control, usado pela primeira vez por Mattson em sua tese em 1996. Não havia como, no texto do Bob Martin, ele tratar, explicitamente, de IoC.

Anos depois, em 2004, o Fowler em conjunto com outros autores discutiram os termos e o Fowler publicou o artigo. 

Enfim, IMO, há sim uma confusão na terminologia, muito em consequência do artigo do Fowler. Creio eu que o mais sensato, quando se discute sobre IoC, é primeiramente definir o termo, pois é fácil entrar em uma argumentação, que eu vejo ser o caso aqui, onde uma parte está argumentando baseando-se na definição original e outra parte está argumentando baseada na definição popular - popular no sentido de ter mais aceitação, sem qualquer demérito.

- Pedro Reys

2010/12/8 Thiago C. Santos <thiago.csantos.me@gmail.com>

[Bruno Gross]

"Toda unanimidade é burra"
Nélson Rodrigues

2010/12/8 Pedro Reys <pedr...@gmail.com>

--
Visite: www.comprasnoexterior.com.br, www.upalele.com

att.
Bruno Gross
(21) 83422729

[Vinicius Quaiato]

Não entendo o pq da discussão.

IoC é algo bem simples e claro: remover de uma classe o controle sobre suas dependências.

Pedro isso é uma falácia em termos. Se o mercado convencionou isso, não há nenhum prejuízo na forma como as coisas estão, não vejo o por que disso estar errado ou ser uma falácia.

Sério, NINGUÉM aqui está dizendo que IoC é DI, sério, e é por isso que TODOS estão pedindo ao Henry para ele expor sua opinião ao invés de ficar referenciando um parágrafo de um texto.

TODOs aqui já disseram e mostraram que não entendem IoC como DI.

Só que não dá pra conevrsar e discutir com quem simplesmente diz "isso não é IoC".

2010/12/8 Pedro Reys <pedr...@gmail.com>

[Marcus Alexandre Silva]

IoC para mim é simplesmente um recipiente que garante que qualquer utilizador de um plugin não precise de conhecer sua implementação, bastando apenas ter conhecimento do seu contrato ou interface. Inversão de Controle, puro e simples

Já a Di é apenas um conceito para injetar as dependências de um  determinado objeto e o construir em tempo de execução.

Este conceito leva em consideração 3 maneiras de realizar esta injeção: Constructor Injection, Setter Injection, e Interface Injection, todas estas 3 maneiras são tipos de IoC, baseando-se no conceito que coloquei acima.

 

Ou seja, DI não é IoC, mas por DI eu consigo utilizar IoC no seu conceito mais puro.....

 

Não sei porque de toda a discurção....

[Henry Conceição]

Eu pensei que ja tinha respondido está pergunta, no momento que o Juan
havia perguntado.

Ioc é sobre controle de execuçao, e nao controle resolucao de
dependencias. Vc inverte este controle que entrega todo ele para outra
entidade (containers é a mais comum). Se vc faz um lookup por um
service dentro de outro service, imo, vc esta reassumindo este
controle. O IoC se perdeu, mas ficou o DI.

On Dec 8, 3:33 pm, Vinicius Quaiato <vinicius.quai...@gmail.com>
wrote:

> Não entendo o pq da discussão.
>
> IoC é algo bem simples e claro: remover de uma classe o controle sobre suas
> dependências.
>
> Pedro isso é uma falácia em termos. Se o mercado convencionou isso, não há
> nenhum prejuízo na forma como as coisas estão, não vejo o por que disso
> estar errado ou ser uma falácia.
>
> Sério, NINGUÉM aqui está dizendo que IoC é DI, sério, e é por isso que TODOS
> estão pedindo ao Henry para ele expor sua opinião ao invés de ficar
> referenciando um parágrafo de um texto.
> TODOs aqui já disseram e mostraram que não entendem IoC como DI.
>
> Só que não dá pra conevrsar e discutir com quem simplesmente diz "isso não é
> IoC".
>

> 2010/12/8 Pedro Reys <pedror...@gmail.com>

>
> > Bom,
>
> > Primeiro com relação a: "É o que o mercado aceita/diz/define". Isso é uma

> > falácia, Argumentum ad Populum<http://en.wikipedia.org/wiki/Argumentum_ad_populum>,

> > e vocês sabem disso. Aliás, é essa mesma falácia usada por pessoas que
> > defendem Waterfall, PMI e outras coisas que tentamos mudar a maneira que o
> > mercado entende, não é mesmo?
>
> > Voltando ao assunto da thread: É de fato confusa a distinção de termos
> > entre IoC, Dependency Injection, Dependency Inversion. Neste link aqui há um
> > texto que dá uma explicação temporal para isso:
> >http://www.picocontainer.org/inversion-of-control-history.html
>
> > <http://www.picocontainer.org/inversion-of-control-history.html>O texto do
> > Bob Martin é de 1994, o termo Inversion of Control, usado pela primeira vez
> > por Mattson em sua tese em 1996. Não havia como, no texto do Bob Martin, ele
> > tratar, explicitamente, de IoC.
>
> > Anos depois, em 2004, o Fowler em conjunto com outros autores discutiram os
> > termos e o Fowler publicou o artigo.
>
> > Enfim, IMO, há sim uma confusão na terminologia, muito em consequência do
> > artigo do Fowler. Creio eu que o mais sensato, quando se discute sobre IoC,
> > é primeiramente definir o termo, pois é fácil entrar em uma argumentação,
> > que eu vejo ser o caso aqui, onde uma parte está argumentando baseando-se na
> > definição original e outra parte está argumentando baseada na definição
> > popular - popular no sentido de ter mais aceitação, sem qualquer demérito.
>
> > - Pedro Reys
>

> > 2010/12/8 Thiago C. Santos <thiago.csantos...@gmail.com>

>
> >> Que paradoxo...
>
> >> Ninguém disse (IoC = DI), apenas que se atinge a inversão de controle com
> >> o DI ou com SL.
>
> >> Thiago C. Santos
>

> >> 2010/12/8 Henry Conceição <henry.concei...@gmail.com>

> ...
>
> read more »

[Marcus Alexandre Silva]

Henrry,

 

Interessante sua definição, apesar de me soar incorreta baseado no que eu ando lendo....

Mas mesmo assim, muito interessante.

Você pode me passar de onde você se baseou? Livro ou Site...

Aguardo,

 

Marcus

> ...
>
> read more »

[Vinicius Quaiato]

Sem IoC:

public class Foo

{

        public void Bar()

        {

            var fooz = new Fooz();

        }

}

Com IoC usando DI:

public class Foo

{

        public void Bar(Fooz fooz)

        {

            //do something with fooz

        }

}

E pq isso é IoC? Simples:

public class SomeApplicationLevelClass

{

    public void SomeApplicationMethod()

    {

        var someFooz = GetsomeFooz();

        new Foo().Bar(someFooz);

    }

}

Viu, o controle não está mais com a classe Foo, saiu de lá. De acordo com sua idéia isso é IoC sim, afinal o lookup não está em Foo, oras. Agora pouco importa se SomeApplicationLevelClass é ou usa um container para isso, o que importa é que Foo perdeu o controle através de DI.

2010/12/8 Marcus Alexandre Silva <inf.marcu...@gmail.com>

[Thiago C. Santos]

Mesmo nessa sua linha de pensamento (que eu concordo ate certo ponto), acho que o IoC não se perde, simplesmente é uma forma diferente de atingi-lo.

Thiago C. Santos

2010/12/8 Vinicius Quaiato <vinicius...@gmail.com>

[Pedro Reys]

Vinicius, 

A falácia não é o que o mercado convencionou, mas sim o argumento que diz que A está correto porque a maioria concorda que A está correto.

Podemos discutir isso em PVT para não desviar ainda mais o assunto da thread :P

- Pedro Reys

2010/12/8 Vinicius Quaiato <vinicius...@gmail.com>

[Vinicius Quaiato]

Sim esse papo de "A voz do povo é a voz de Deus" pode ser perigoso. Mas não dá pra remar contra a maré, como eu disse, em uma situação em que não há prejuízos, diferente do que foi colocado do waterfall :P

2010/12/8 Pedro Reys <pedr...@gmail.com>