Como implementar um modelo de objetos que não interfira o modelo Relacional, usando o RepositoryPattern?

[Daniel Moreira Yokoyama]

Olá pessoal.

 

Há algum tempo atrás eu havia perguntado aqui a respeito da existência de um ORM que fosse baseado em RoleInterfaces.

 

Em resumo para quem não leu (Se tiverem lido e quiserem passar pro restante do email, pulem o trecho identado):

 

Apresentei um modelo de acesso a dados que eu tenho, onde um único repositório é usado para todos os objetos do meu modelo e coordena internamente os repositórios da aplicação, que são baseados em Interfaces, ou seja, 1 Interface para cada Tabela, 1 Repositório para cada Interface. Eles recebem os objetos, verificam se são responsáveis pela persistência deles através de sua interface e assumem o controle.

 

A implementação disso foi bastante divertida, mas, como podem imaginar, levou bastante tempo para atingir uma certa maturidade. E finalmente agora que está madura, estamos pensando em refatorar.

 

A idéia inicial é clara: Queremos suportar LINQ (por que está sendo muito ruim ter que implementar novos métodos para cada novo filtro que nos vem em mente, como SelectByDate(datetime From, datetime til) e SelectByCategory(Category Category)...)

 

Estou entre dois dilemas, me divertir refazendo isso (desta vez tentando torná-lo reutilizável para aproveitar nos projetos futuros) ou me deixá-lo como está e me divertir implementando o IQueryable<>, foi por isso que escrevi naquele período.

 

 

Mas eu percebi que estava fazendo a pergunta errada. E talvez, agora, pensando melhor, eu consiga expressar o que realmente queira alcançar. Por que fizemos tudo aquilo em primeiro lugar? Fácil, por que tentamos encontrar uma forma de fazer com que nossos modelos (OO e Relacional) não se interferissem. Tabelas normalizam dados e Classes normalizam comportamento. Assim, classes diferentes que compartilham parte de sua estrutura de dados precisam persistí-los na mesma tabela... Não sei como é nos sistemas que vocês normalmente implementam, mas no nosso, esse compartilhamento de de estrutura acontece em diversos pontos do sistema e buscamos uma solução que tentasse fazer com que as tabelas interferissem no modelo OO e vice-versa.

 

Por este motivo, coloquei as estruturas de dados das tabelas em interfaces nomeadas de acordo com o seu contexto e fiz com que minhas classes implementassem estas interfaces e whallah... atingimos o objetivo. Foi nos sugerido diversas outras formas de fazê-lo, como criar classes de objetos que iriam compor o objeto no modelo OO (o que faria com que o relacional interferisse no design das classes), e nós estamos decididos a tentar encontrar uma solução que continue nos apontando para o objetivo, e é este objetivo que forma a pergunta certa a ser feita:

 

Como implementar um modelo de objetos que não interfira o modelo Relacional, usando o RepositoryPattern? Eu já coloquei na minha cabeça que talvez a solução seja estudar melhor o tão falado DDD (do qual já li um bocado mas nunca me aprofundando muito por ter que dar prioridade a outras coisas) e, talvez, o Giovanni tenha algo a dizer a respeito. Então, é claro, me comprometo a estudar a respeito disso e talvez, assim, já obter a resposta para a pergunta. Mas, mesmo assim, gostaria de levantar esta discussão. Acredito que ela tem tudo a ver com o contexto do grupo. Acredito que ela só tem a somar para todos os participantes ou, no mínimo, servir de bom exercício para aqueles que já dominem as técnicas usadas para atingir este objetivo.

 

Usando ORM ou não, eu gostaria de propor a elaboração de um modelo de acesso a dados que seguisse esta premissa (OO X relacional sem se inteferirem). Talvez eu descubra que isso não é nenhum bixo de 7 cabeças (e fique com cara de idiota afterall, hehehe), talvez todos nós descubramos que não existe uma forma elegante e reutilizável de se implementar isso ou ainda, talvez, descubramos uma oportunidade, como comunidade de arquitetos, de contribuir com uma nova técnica, um novo pattern, para a comunidade de desenvolvimento em geral (não esquentem, geralmente eu sou meio utópico). Independente da conclusão, acho que todos temos a ganhar com isso, quer seja conhecimento, quer seja experiência.

 

O que acham?

 

Atenciosamente,

 

Daniel Moreira Yokoyama.

http://halonfullestuse.wordpress.com/

 

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."

(HAL 9000)

 

 

[Alexandre Valente]

Oi Daniel,

Entendo sua questão e já refleti sobre isto também. O que eu acho porém é que a impedância objeto/relacional faz com que este mapeamento seja sempre uma questão complexa, e daí é mais simples vc ter um modelo mais proximo do banco do que mais distante. Quanto mais distante, mais complicadas serão suas estruturas de mapeamento.

Sim, acho que seria possível vc encapsular qqer modelo de banco com um repositório "on steroids"... Porém não creio que o custo justifique já que não será uma tarefa simples. Eu acho que isto será possível se um dia tivermos um banco de dados mais orientado a objeto, mas isto é uma promessa que há anos não avança.

E se vc pensar no cliente, ele não quer saber se usamos um modelo OO ou um modelo relacional. Ele quer a aplicação rodando com o menor custo possível. Desta forma, manter o modelo proximo do banco é o mais sensato a fazer. No nosso caso, a gente projeta sempre o banco para ser o mais object-friendly possivel.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

2009/12/15 Daniel Moreira Yokoyama <moreira....@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

[tucaz]

Cada vez mais eu concordo seguidamente com o Alexandre. É isso ai, sem
tirar nem por.

On 15 dez, 10:06, Alexandre Valente <alexandre.g.vale...@gmail.com>
wrote:

> Oi Daniel,
>
> Entendo sua questão e já refleti sobre isto também. O que eu acho porém é
> que a impedância objeto/relacional faz com que este mapeamento seja sempre
> uma questão complexa, e daí é mais simples vc ter um modelo mais proximo do
> banco do que mais distante. Quanto mais distante, mais complicadas serão
> suas estruturas de mapeamento.
>
> Sim, acho que seria possível vc encapsular qqer modelo de banco com um
> repositório "on steroids"... Porém não creio que o custo justifique já que
> não será uma tarefa simples. Eu acho que isto será possível se um dia
> tivermos um banco de dados mais orientado a objeto, mas isto é uma promessa
> que há anos não avança.
>
> E se vc pensar no cliente, ele não quer saber se usamos um modelo OO ou um
> modelo relacional. Ele quer a aplicação rodando com o menor custo possível.
> Desta forma, manter o modelo proximo do banco é o mais sensato a fazer. No
> nosso caso, a gente projeta sempre o banco para ser o mais object-friendly
> possivel.
>
> abs
>
> Alexandre Valente
> MCSE+I, MCSD, MDCBA, ITIL, CSM
> agvalente.wordpress.com
>

> 2009/12/15 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>
> > Olá pessoal.
>
> > Há algum tempo atrás eu havia perguntado aqui<http://groups.google.com/group/dotnetarchitects/browse_thread/thread/...>a respeito da existência de um ORM que fosse baseado em
> > RoleInterfaces <http://martinfowler.com/bliki/RoleInterface.html>.

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

[Juan Pedro A. Lopes]

Eu geralmente concordo com esse pragmatismo. Mas temos que lembrar que grandes empresas muitas vezes usam bancos legados e fundamentam toda sua base de informação neles.

Não é raro encontrar um cliente que use um grande set de aplicações da Oracle, em bancos onde existem packages beirando alguns milhões de linhas de código (criados pela própria fábrica da Oracle). Consultar os dados de um usuário às vezes pode significar chamar um function dentro de um package escondido usando um dblink com outro usuário. Pra isso serve o mapeamento rico.

2009/12/15 tucaz <tuc...@gmail.com>

--
Kind regards,
Juan Lopes

juanp...@gmail.com
con...@juanlopes.net
http://juanlopes.net
http://twitter.com/juanplopes

"E se o mundo não corresponde em todos os aspectos a nossos desejos, é culpa da ciência ou dos que querem impor seus desejos ao mundo?" - Carl Sagan

[Daniel Moreira Yokoyama]

Bom, eu concordo com você Alexandre, mas acho que esta não é exatamente a melhor resposta.

 

Entenda, eu poderia chegar a esta conclusão facilmente e me contentar com o que eu já implementei, me conformando que até foi divertido mas está longe de se tornar novamente um desafio.

Não gosto muido desse raciocínio, e por isso fiz o convite a todos os colegas para pensarem numa forma de atingir este objetivo, ainda que custoso, como um desafio para todos nós, no sentido de, conseguindo resolver este impasse, tornar seu custo aceitável reutilizando a aplicação prática que conseguirmos criar.

Entendam, já não mais estou falando de amadurecer minha própria solução... estou disposto a encarar uma completamente nova. (antes que pensem que estou apenas pegando o meu problema e pedirem para vocês resolverem).

E neste contexto, estou me livrando da figura do cliente (que tende a impor constraints) e trazendo isto para o meu interesse (e, talvez, de todo o grupo, ou até, de toda a comunidade).

 

Daí a proposta. Trazer para a mesa de discussão uma solução para algo que é um problema geral: Ou você fere um dos modelos (relacional ou OO) para suportar o outro, ou você arca com um custo de desenhar uma solução que evite isto.

 

Alguém pagou o custo de implementar o Hibernate, o que significa que ele deixou de lado por um instante a figura do cliente e cuidou de fazer algo que mais tarde foi aderido por uma imensa comunidade de desenvolvimento e que, hoje, já não pensa nas constraints estabelecidas pelo cliente na hora de incorporá-lo ao projeto. Por que ele já está pronto, basta utilizá-lo. Por que não podemos ir no mesmo propósito e correr o risco de trazer mais um benefício enorme para nós mesmos e toda a comunidade arcando com o custo uma vez para nunca mais ter que arcar novamente?

 

Juan, exatamente para este cenário, que esta idéia acaba se tornando ainda mais útil... Alcançando uma solução deste porte, podemos ficar completamente despreocupados se o banco já existe, ou se o modelo já existe... tanto faz.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/12/15 Juan Pedro A. Lopes <zero...@gmail.com>

[Eduardo Menoncello]

Se quiser um exemplo disso, siga acompanhando o PDN Financas, http://www.pensando.net

Lá em breve será implementado.

At.

2009/12/15 Daniel Moreira Yokoyama <moreira....@gmail.com>

Olá pessoal.

--

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

--
At.

Eduardo Menoncello
--------------------------------------
Podcast Pensando DotNet
http://www.pensando.net
twitter: @edumenoncello

[Daniel Moreira Yokoyama]

?

 

Simples assim? rs...

 

De repente falamos de algo que seria custoso demais e o desafio que seria, querendo mobilizar o grupo a desenhar algo neste propósito e aí... hehehe

 

"Siga acompanhando o PDN Finanças... em breve será implementado..."

 

Hehehe... fiquei curioso Eduardo... sinceramente, vou me sentir ridículo... hehehe.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/12/15 Eduardo Menoncello <eduardo.m...@gmail.com>

[Henry Conceição]

Daniel,

Sua intenção é boa, mas eu acho que com oq é oferecido pelos rdbms hj,
não tem mais como avançar muito nesta area:

O problema da polimorfia/herança não tem uma solução boa o bastante
para acomodar qq tipo de modelo, imho. Qq um dos patterns (Concrete
tables, Single table ou Class table Inheritance) apresentam problemas
qdo começamos a trabalhar com super classes e um volume significativo
de dados: inner joins lentos, tabelas muito espaçadas e indexes
ineficientes ou queries extremamente complexas.

Tem o problema da recursividade também, que mesmo no sql nativo é uma
bela gambiarra.

Mas se vc estiver mesmo disposto a trabalhar, o meu conselho é para vc
abrir o código e ir trabalhando na implementação, enquanto tenta
vender a ideia e trazer novos contributors para o projeto.

On Dec 15, 3:39 pm, Daniel Moreira Yokoyama

> Daniel Moreira Yokoyama.http://halonfullestuse.wordpress.com/

>
> "I am putting myself to the fullest possible use, which is all I think that
> any conscious entity can ever hope to do."
> (HAL 9000)
>

> 2009/12/15 Juan Pedro A. Lopes <zerova...@gmail.com>

>
>
>
> > Eu geralmente concordo com esse pragmatismo. Mas temos que lembrar que
> > grandes empresas muitas vezes usam bancos legados e fundamentam toda sua
> > base de informação neles.
>
> > Não é raro encontrar um cliente que use um grande set de aplicações da
> > Oracle, em bancos onde existem packages beirando alguns milhões de linhas de
> > código (criados pela própria fábrica da Oracle). Consultar os dados de um
> > usuário às vezes pode significar chamar um function dentro de um package
> > escondido usando um dblink com outro usuário. Pra isso serve o mapeamento
> > rico.
>

> > 2009/12/15 tucaz <tuca...@gmail.com>

> >>http://groups.google.com/group/dotnetarchitects/browse_thread/thread/..<http://groups.google.com/group/dotnetarchitects/browse_thread/>.>a

> ...
>
> read more »

[Juan Pedro A. Lopes]

Eu sequer entendi o problema :P

2009/12/15 Henry Conceição <henry.c...@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]

Talvez um exemplo:

Dado um modelinho simples:

class User

class Customer : User

class Vendor : User

Todo query/operação que for feita em cima de user, tera que retornar
os dados referentes a toda hierarquia, pq um user pode ser um customer
ou vendor, e depois de vc carregar o user a possibilidade do cast
existe e neste momento, vc tem que estar com a entidade preenchida (ou
hidratada pra usar o jargao).

Com concreate tables, as queries serao cheias de unions, innerjoins e
etc. No Single table, vc tem uma tabela só que pode ficar cheia de
campos nulos

On Dec 15, 4:51 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote:
> Eu sequer entendi o problema :P
>

> 2009/12/15 Henry Conceição <henry.concei...@gmail.com>

> ...
>
> read more »

[Henry Conceição]

continuando...

e dependendo do tamanho da tabela, fazendo qq inner join virar uma
bomba.

No class table, o tamanho da tabela pai e q quantidade de joins
gerados praticamente anula o uso dele em casos reais.

Para todos os três casos, vc tem o problema em potencial de
associações não lazy.

> ...
>
> read more »

[Juan Pedro A. Lopes]

Henry, esse problema eu entendi.

Não entendi qual foi o problema proposto pelo Daniel que o NHibernate já não resolva.

2009/12/15 Henry Conceição <henry.c...@gmail.com>

> ...
>
> read more »

--
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]

Ha, sorry.

On Dec 15, 5:09 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote:
> Henry, esse problema eu entendi.
>
> Não entendi qual foi o problema proposto pelo Daniel que o NHibernate já não
> resolva.
>

> 2009/12/15 Henry Conceição <henry.concei...@gmail.com>

> ...
>
> read more »

[Daniel Moreira Yokoyama]

2009/12/15 Henry Conceição <henry.c...@gmail.com>

Mas se vc estiver mesmo disposto a trabalhar, o meu conselho é para vc
abrir o código e ir trabalhando na implementação, enquanto tenta
vender a ideia e trazer novos contributors para o projeto.

Talvez tenha razão. Posso começar a pensar em algo por minha conta... iniciar uma pesquisa e começar a entender o problema e pensar em uma implementação. Talvez, de acordo com o progresso, chame a atenção de outros interessados.

[Daniel Moreira Yokoyama]

2009/12/15 Leo D <leod....@gmail.com>

Daniel, será que você não está querendo escrever uma solução genérica
para resolver "todos os problemas"?

 

Na verdade estou falando de um problema só. E vejam, é um problema que eu consegui solucionar, mas quero refazê-lo, tornando seu uso reaproveitável em outros projetos, ou seja, criar um framework, para não ter o mesmo trabalho toda vez que quiser usá-lo e, ainda assim, deixá-lo extensível, pensar em outros aspectos importantes, como LINQ, Orientação a Serviços, etc.

 

Acho que isso pode estar tornando seu projeto
ambicioso demais.

Eu esqueci de ressaltar. Isto não é um projeto. Fiz parte de uma equipe onde implementamos isso, em uma empresa que é cliente de si mesma, ou seja, o produto dela é um software, os clientes não pagam o desenvolvimento, mas sim o acesso ao software. A empresa em si não é exatamente preocupada em seguir essa ou aquela tendência mas dá total liberdade a equipe de cuidar da implementação e foi neste clima de liberdade que esta solução (baseada em RoleInterfaces) surgiu e amadureceu, num momento em que havia pouca ou nenhuma manutenção para se fazer.

 

E é exatamente num momento como este que a equipe se encontra agora e resolveu entrar em contato comigo para pensar em uma forma de fazer esta solução suportar LINQ, mas durante a nossa conversa, eu mesmo me dei conta do quanto isso seria útil se fôsse reaproveitável.

 

Então, não. Não acho que está sendo ambicioso demais para um projeto, porque não existe um projeto propriamente dito. Coding for Fun mesmo.

 

Tente identificar onde está o limite disso - acho que o esforço de
escrever código deve ser direcionado à solução de problemas reais, e não
visando, sempre, acomodar conceitos.

Mas eu considero isto um problema real. Apesar de saber contorná-lo não significa que solucionamos o problema. Certo?

 

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

[]s

> Eu sequer entendi o problema :P
>

[Phillip Calçado]

Oi,

2009/12/15 Alexandre Valente <alexandre...@gmail.com>:

> E se vc pensar no cliente, ele não quer saber se usamos um modelo OO ou um
> modelo relacional. Ele quer a aplicação rodando com o menor custo possível.
> Desta forma, manter o modelo proximo do banco é o mais sensato a fazer. No
> nosso caso, a gente projeta sempre o banco para ser o mais object-friendly
> possivel.

Assim como seu cliente também não quer saber se aquela alteraçãozinha
que para ele é tão simples vai implicar em mil horas de trabalho
porque a arquitetura não foi feita de uma maneira flexível o
suficiente -afinal, ele não está comprando um binário executável, está
comprando o tempo de um profissional qualificado para criar um sistema
de acordo com suas necessidades.

Um paciente que vai ao médico não liga como o médico o vai ajudar,
desde que ele fique curado -da maneira mais barata possível. Mas se um
mês após ser curado ele tem uma doença pior por causa do tratamento
efetuado ele não vai ficar muito feliz...

[]s

--
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br

[Daniel Moreira Yokoyama]

Certo,

 

O NHibernate realmente faz mapeamento para interfaces, como acabei de constatar. Então ele já torna minha proposta de certa forma inútil. Heheheh.

 

Mas não deixou de ser uma lição. Agora só vou mesmo precisar focar no suporte ao Linq (que era nosso objetivo original) mas isso já não é mais nenhum candidato a se tornar framework para a comunidade.

 

Eu quero só esclarecer aqui, antes de finalizar o assunto, que tudo o que eu já tinha visto a  respeito de ORM's me fazia ter esta idéia de que no fundo no fundo estávamos trazendo o modelo relacional para o modelo de objetos. De certa forma, isto estava claro pra mim desde a primeira vez que ouvi falar de Hibernate, em 2004 (sim, o Hibernate original para Java, quando eu me aventurei pro lado de lá).

 

De lá pra cá, somente recentemente é que resolvi voltar a minha atenção para ORM's novamente e isto foi devido ao anúncio do EntityFramework 4 por que em uma apresentação que assiti no PDC do ano passado, foi apresentado um recurso interessantíssimo chamado CodeOnly. Que funciona sem um edmx no meio, ou seja, você tem suas classes com seu modelo OO e tem suas tabelas e monta containers com contextos usando Convention Over Configuration. E este seria um mundo perfeito. Suporta Linq e tudo o mais. Só tem um problema: O EF4 não mapeia interfaces.

 

E talvez, pela frustração com o EF4 e pela falta de informação do NH (talvez agora eu até descubra que ele suporte convention over configuration e, ainda, Linq), talvez por tudo isso, eu resolvi achar que havia pensado em algo novo. hehehehe...

 

Esclarecido tudo, valew pelos conselhos e pela ajuda.

Atenciosamente,

Daniel Moreira Yokoyama.

http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/12/15 Juan Pedro A. Lopes <zero...@gmail.com>

[Phillip Calçado]

Oi,

2009/12/15 Daniel Moreira Yokoyama <moreira....@gmail.com>:

> Como implementar um modelo de objetos que não interfira o modelo Relacional,
> usando o RepositoryPattern?
> Eu já coloquei na minha cabeça que talvez a
> solução seja estudar melhor o tão falado DDD

Nem Domain-Driven Design nem Repositórios estão diretamente
relacionados com o que você está fazendo. Por algum motivo existe em
.Net uma tendência em chamar de Repositório qualquer coisa que seja a
fronteira com o banco de dados, pode estar vindo daí a confusão.

Eu não entendi onde você está sendo problemas. Eu, sinceramente, não
vejo motivos para você mantêr dois modelos separados -pelo contrário,
s;o vejo um mar de problemas que eu já vivi tantas vezes na vida
quando o tive que fazer- mas se você quer que as coisas sejam assim,
seja lá por qual motivo, basta dar uma olhada na literatura a respeito
de Mapeamento Objeto-Relacional.

Se você olhar o POEAA, o site do Scot Ambler e na biblioteca da ACM
vai perceber que muito antes de existirem frameworks e containers de
persistência existiam técnicas para se fazer este mapeamento de
maneira manual. Se você não quer lidar com o banco de dados em si
manualmente (abre conexão, mantêm cache, etc.) então você tem apenas
uma transformação de um modelo relacional para o seu modelo OO. Algo
assim:

Tabelas <-> Modelo Objeto-Relacional <-> Modelo OO

Onde Tabelas é seu modelo de banco, Modelo OR é um modelo de objetos
criado com a finalidade de traduzir uma coisa para a outra e Modelo OO
seu domínio de aplicação (este sim podendo utilizar DDD, Repositórios
e tudo mais).

A menos que eu não tenha entendido nada do seu problema acho que a
solução está presente nas referências que mencionei acima.

[Alexandre Valente]

Oi Phillip,

Nossa, pela primeira vez em muitos emails seus, concordo completamente que o que vc escreveu! Exatamente o que eu penso! :-) :-)

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com.

2009/12/16 Phillip Calçado <pcal...@gmail.com>