Nova aplicação

[Peneluc]

Pessoal,

Estou desenvolvendo uma aplicação em .NET com NHibenate e
acho que vou usar Log4j. Apenas isso por enquanto.

Cansei de tentar entender o MVC e, por achar que estava perdendo
muito tempo, distribui minha nova aplicação da seguinte maneira:

1. WebForms (Interface, páginas WEB);

2. BP - Camada de Negócio (Regras do sistema);

3. BE - Camada de Entidade (Classes do NH);

4. BM - Camada de Gerenciamento (Manager/Proxy);

5. DALC - Camada de Persistencia (Manutençaão e Consultas);

6. Camada de Suporte (Emails, LDAP, Webservices, etc);


WF -> BP -> BM -> DALC
<------------ BE ------------->



O que vocês acham?

Perguntas:

1. Qual as deficiências desta estrutura ?

2. Amanhã, posso modificar para uma estrutura MVC sem muito prejuízo ?

Aguardo ancioso os comentários de todos!

Um abraço,

Peneluc

[Petrônio Cândido de Lima e Silva]

Peneluc,

Uma dúvida: O seu BE é uma espécie de modelo anêmico?

Ats.

2009/11/27 Peneluc <pen...@gmail.com>:

--
Petrônio Cândido de Lima e Silva
Analista de Sistemas

(38) 9164 2910
(38) 3224 2880

[Peneluc]

Olá Petrônio,

Não se ele se encaixa no modelo que Fowler descreveu.

O meu BE é basicamente get e set de atributos que representam uma entidade do banco.

Segue exemplo:

using System;
using System.Collections.Generic;
using System.Text;

namespace Projeto.Business.BusinessEntity
{
    [Serializable]
    public class BEUsuario : IBusinessEntity
    {

        private Int32 identificacao;

        private Int64 matricula;
        private string nome;


        public Int32 Identificacao
        {
            get { return identificacao; }
            set { identificacao = value; }
        }

        public Int64 Matricula
        {
            get { return matricula; }
            set { matricula = value; }
        }

        public string Nome
        {
            get { return nome.Trim(); }
            set { nome = value.Trim(); }
        }

        public override bool Equals(object obj)
        {
            if (this == obj) return true;
            if ((obj == null) || (obj.GetType() != this.GetType())) return false;
            BEUsuario castObj = (BEUsuario)obj;
            return (castObj != null) &&
                (this.Chave == castObj.Chave) &&
                (this.Identificacao == castObj.Identificacao);
        }

        /// <summary>
        /// local implementation of GetHashCode based on unique value members
        /// </summary>
        public override int GetHashCode()
        {

            int hash = 57;
            hash = 27 * hash * Chave.GetHashCode();
            hash = 27 * hash * Identificacao.GetHashCode();
            return hash;
        }

    }
}

2009/11/27 Petrônio Cândido de Lima e Silva <petronio...@gmail.com>

--

Peneluc

[Emmanuel G. Brandão]

É anêmico! Você separou o comportamento dos seus objetos de domínio, colocando-os na camada BP, dos estado dos objetos de domínio, que estão na camada BE. Fora que MVC diz respeito somente a interface, então MVC e modelo rico não são a mesma coisa...

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

___________________________________
Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Apague também os endereços dos amigos que receberam juntamente com você a mensagem, antes de enviar;
3 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.

2009/11/27 Peneluc <pen...@gmail.com>

[Peneluc]

Oh Emmanuel,

Já que vc respondeu o Petrônio, você poderia me dizer
se o meu novo projeto tem alguma deficiência conhecida
por vocês na sua arquitetura?

Fico grato!

Um abraço.

2009/11/27 Emmanuel G. Brandão <egomes...@gmail.com>

--

Peneluc

[Emmanuel G. Brandão]

A resposta foi a sua pergunta... Se não conhece os termos, faça uma pesquisa no Google que você vai entender as críticas.

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

___________________________________
Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Apague também os endereços dos amigos que receberam juntamente com você a mensagem, antes de enviar;
3 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.

2009/11/28 Peneluc <pen...@gmail.com>

[Peneluc]

Emmanuel,

Vamos lá, o que eu disse foi:

"Olá Petrônio,

Não se ele se encaixa no modelo que Fowler descreveu.

O meu BE é basicamente get e set de atributos que representam uma entidade do banco."

Quer dizer, NÃO AFIRMEI NADA, muito pelo contrário, disse que NÃO SABIA.

Então vamos com calma nos seus comentários.
Se não quer comentar, fique na sua e evite gastar seu tempo.

Evite ser mal educado e aprenda a ler, pois você mostrou ser uma
pessoa leviana e aproveitadora.

Saudações,

Peneluc

2009/11/28 Emmanuel G. Brandão <egomes...@gmail.com>

--

Peneluc

[Emmanuel G. Brandão]

Desculpa se lhe ofendi de alguma forma, eu apenas respondi a sua pergunta e lhe pedi que procurasse os termos, não sei onde isso me torna leviana e aproveitadora (me aproveitei do que?).

Meu primeiro e-mail responde a sua pergunta, veja seu modelo é anêmico eu não respondi ao Petrônio e sim a você, só que fiz isso pelo último e-mail da thread.

E como falamos muito de modelo anêmico aqui, achei que conheceria o termo, já que ninguém mais respondeu a thread escrevi que você procurasse no Google o termo.

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

___________________________________
Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Apague também os endereços dos amigos que receberam juntamente com você a mensagem, antes de enviar;
3 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.

2009/11/29 Peneluc <pen...@gmail.com>

[Peneluc]

Pois é, vou tentar não protelar mais o assunto.

Porque você já estragou a minha thread desviando todo o assunto.
Vou ter que criar outra mesmo...

Acreditando, como você, que ninguém se ofendeu, vou tentar explicar:

- Leviano porque se precipitou em achar que não entendi os termos;
- Aproveitador porque buscou uma situação de ERRO, quando na verdade deveria tentar ajudar;

Quando uma pessoa vem à lista buscando ajuda em uma questão, TODOS esperam que esta já
tenha esgotado todos os meios de pesquisa (google, bing, etc). Entretanto, todos deveriam
tentar responder a questão, mesmo que indicando outra thread sobre o assunto. Sacou?!

É pra isso que serve uma lista de discussão. É OFF-TOPIC chama o moderador.
No mais, a lista é para AJUDAR e não para criticar ou menosprezar o participante.

No meu caso, perguntei sobre a estrutura da minha aplicação.
Quem perguntou sobre o modelo anêmico foi o colega Petrônio, que espero você tenha respondido.
Por isso, eu disse que você respondeu a ele.

Agora não entendo o que leva uma pessoa em plena consciência responder na lista:

"Procure no Google!"
ou

"Se não conhece os termos,
faça uma pesquisa no Google que você vai entender as críticas."

O que você esperava como resposta ?

Isso NÃO é admissível até quando a pergunta é primária.

Portanto, as suas 2 mensagens para a thread foram, no mínimo, sem sentido.

Espero que nas próximas discussões analise com cuidado antes de responder.

Mesmo assim, entendo a sua dificuldade. Por isso, ficamos sem ressentimentos,

Peneluc

2009/11/30 Emmanuel G. Brandão <egomes...@gmail.com>

--

Peneluc

[Vinicius Quaiato]

Calma lá gente...

Não precisamos dessa agressividade toda.

Acredito que o que o Emmanuel disse não foi "Se vira, procure no Google e pare de amolar"... Tenho certeza de que não foi isso.
Porém, em fóruns e listas de discussões à vezes nossas intenções não são tão claras quanto queremos.

Vamos tentar deixar esse "problema" de lado e continuar colaborando com o grupo de maneira saudável. Continuar essa discussão aqui não vai levar ninguém a lugar nenhum, apenas estraga o bom clima que existe entre os participantes.

Acho que não interessa quem começou oque. O Emmanuel se desculpou por ter te ofendido e reconheceu que errou, já basta.

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Google Talk: vinicius.quaiato

Twitter

--- @ WiseStamp Signature. Get it now

2009/11/30 Peneluc <pen...@gmail.com>

[Peneluc]

OK, Vinicius, pra mim já é o fim!

Agora minha thread já era...

Como disse, sem ressentimentos.

Peneluc

2009/11/30 Vinicius Quaiato <vinicius...@gmail.com>

--

Peneluc

[Gustavo Rocha]

Peneluc,

costumo pouco me fuder pras discussoes bizonhas daqui mas vou me meter dessa vez.

Acho eu houve uma confusao, mal entendido, coisas que o email pode acarretar por nao podermos perceber bem o que a outra pessoa quis transmitir.

Tive a oportunidade de conhecer o Emmanuel pessoalmente e tenho certeza absoluta que em momento algum ele quis ofender ou te cortar, jamais faria isso e acho que ele quis sim responder à sua pergunta. As vezes na pressa acabamos nos expressando mal.

Tambem entendo completamente sua interpretacao da mensagem dele, ficou muito vaga realmente e pareceu pesada.

Mas de novo uma discussao auiq no grupo ta enchendo o saco demais, cara. Isso ta ficando comum por aqui ultimamente. E nao era assim. Pesso falar disso com propriedade. Nao sei pq o aumento de membros leva ao aumento do calor das discussoes. Grande besteira.

Enfim, calma que o petroleo é nosso. Continuem a thread na boa ai que vai render conhecimento como sempre.

Abs.

Gustavo Rocha

2009/11/30 Peneluc <pen...@gmail.com>

[Daniel Porfirio]

Deixando o "Lalalalala" de lado.

Peneluc,

tu poderia me explicar o que te levou a estruturar a sua aplicação assim? Pergunto por trabalhar sozinho e sendo assim eu nao tenho a oportunidade de participar de projetos diferentes com frequencia e nao entendo muito bem quais os requizitos que levam a escolha de X,Y ou Z. Hoje eu tento trabalhar com Modelo Rico usando DDD, coloco sempre em pratica oq aprendo aqui na lista e literaturas paralelas mas me falta vivencia de caso, sera que voce poderia listar os motivos que te levaram a tomar essa decisão.

 

--
[]'s.

A Melhor Maneira De Prever o Futuro é Criá-lo.
------------------------------------------------------------------------------------------------------------------------
Daniel da Silva Porfirio
msn: daniel.s...@gmail.com
------------------------------------------------------------------------------------------------------------------------
Acesse http://www.clickarvore.com.br, registre-se e plante uma árvore diariamente!
Nosso planeta agradece.

[Bruno DAléssio]

Concordo,
segue o jogo, ou melhor a thread.

Quanto as suas dúvidas:

1. Qual as deficiências desta estrutura ?

É complicado avaliar de longe sem conhecer o seu cenário,
mais pelo que você passou brevemente, me parece sim, bem estruturado.

2. Amanhã, posso modificar para uma estrutura MVC sem muito prejuízo ?

Isso vai depender de como você irá estruturar sua camada de apresentação.
Por experiência própria, eu sofri um pouco para converter uma camada de apresentação ja desenvolvida para o ASP.NET MVC.
Talvez possa estar falando besteira, mais o MVC clássico é mais simples para converter algo ja existente do que o "acoplado" ASP.NET MVC.

Novamente repito, é complicado sugerir algo mais "profundo" sem conhecer o cenário.

Abraço e sucesso!

2009/11/30 Gustavo Rocha <gustav...@gmail.com>

[Peneluc]

Obrigado Bruno,

Não se preocupe quanto ao sugerir.
Espero que todos possam fazer o mesmo sem restrições.

A minha segunda pergunta foi devido ao ASP.MVC, hoje, ser uma realidade
para muitos projetos. Sendo assim, no futuro, posso ter vontande de atualizar
este projeto e fiquei curioso sobre o esforço da migração.

Hoje não tenho conhecimento suficiente para investir no ASP.MVC. Por isso,
decidi continuar utilizando WEBForms nos meus projetos pessoais.

Valeu Bruno,

Peneluc

2009/11/30 Bruno DAléssio <bruno...@gmail.com>

--

Peneluc

[Emmanuel G. Brandão]

Peneluc,

Como o Gustavo disse, foi pressa, é difícil responder uma pergunta tão abrangente assim! Por isso eu disse para procurar pelos termos por que entendi, pelo visto erroneamente, que a minha resposta não tinha sido entendida por você! Então esperava que você fosse especificando mais... Pois de uma tacada só analisar e sugerir coisas para uma arquitetura é uma tarefa complexa para quem já esta dentro da questão, quanto mais para quem esta de fora.

No mais, não acho que precisávamos chegar a esse ponto, temos que entender que estamos em um lista, e que o modo como escrevemos as vezes não quer é exatamente o mesmo de quem lê. Todos aqui estamos trabalhando, e não só colaborando com a lista.

Não acho que a sua thread foi para o espaço, é só você continuar em cima da minha crítica algo referente ao seu problema e não a percepção de como eu falei.

Por exemplo, você discorda que eu classifiquei o seu código como anêmico?

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

___________________________________
Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Apague também os endereços dos amigos que receberam juntamente com você a mensagem, antes de enviar;
3 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.

2009/11/30 Peneluc <pen...@gmail.com>

[Bruno DAléssio]

Você está certo,
as vezes tomar decisões em cima de uma tecnologia que não dominamos, custa muito caro.

Na questão da arquitetura da parte de negócios eu poderia sugerir DDD com repositório.
Eu pessoalmente não sou adepto a nenhuma arquitetura, eu foco primeiro a nescessidade (performance, escabilidade, tempo, expectativa, etc)

Como profissionais creio eu que não devemos ser radicais quanto a nada.

Por isso, levei em conta que você pesou essas questões antes de postar aqui.

Quanto a sua escolha de utilizar WEBForms "simples", desde que seja bem estruturado, talvez você ganhe mais com isso.

Siga com sua idéia e no que precisar pode contar.


[],s

2009/11/30 Peneluc <pen...@gmail.com>

[Peneluc]

Olá Daniel,

Rapaz, foi intuitivo mesmo. Por isso a minha dúvida!

Participei de projetos nas empresas por onde passei com diversos
modelos de projetos e ao longo do tempo fui percebendo que esta
estrutura era a que mais me agradava. Por isso, foi uma decisão
mais intuitiva do que baseada em dados estatísticos.

Por isso, perguntei se alguém tinha alguma restrição com este modelo
de distribuição das camadas* desta aplicação.

Tenho algumas visões sobre este modelo, mas não gostaria de falar
agora pois posso atrapalhar os comentários. Por exemplo, observei que
em projetos grandes, com diversos desenvolvedores "indisciplinados" **,
ocorre o fenômeno da multiplicação dos métodos. Apesar de não saber
se é uma característica dessa estrutura ou é comum à todas as outras.

* Por favor, abstraiam a idéia de camada lógica e física, a não ser que
seja relevante.
** São aqueles que "passam o olho" no Diagrama de Seqüência e
escrevem seus próprios métodos, não reaproveitam, etc. No caso,
específico, os desenvolvedores não buscam nos BMs as referências
ao repositório e recriam estas chamadas em diversos BMs ou até no
mesmo com outro nome.

Valeu Daniel,

Peneluc

2009/11/30 Daniel Porfirio <daniel.s...@gmail.com>

--

Peneluc

[Vinicius Quaiato]

Eu diria que essa "multiplicação dos métodos" se dá em arquiteturas/códigos mal feitas. Onde você tem responsabilidades demais em uma classe/método e desta forma não sabe onde estão as coisas que deveria estar em um único lugar.

Sobre a migração para o MVC eu diria que, se nos webforms você não tiver nenhum, ou quase nada, de processamento específico de código, isto é, chamadas para o banco, validações de negócio, etc, sua migração pode ser bem simples. Claro que isso também irá depender da quantidade dos server controls que você usa/depende.

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Google Talk: vinicius.quaiato

Twitter

2009/11/30 Peneluc <pen...@gmail.com>

[Peneluc]

Olá Emmanuel,

No stress, todos nós entendemos o que aconteceu, vamos pra frente!

Agora, respondendo a sua pergunta, parece se encaixar no modelo anêmico sim.

Agora lembre que as classes do BE são as classes do NH. Eu utilizo este BE
como uma camada comum as demais.

WF -> BP -> BM -> DALC
<------------ BE ------------->

Blz, mas as minha perguntas estão no ar ainda, responde se conhece algum
problema que eu possa encontrar com essa estrutura.

Sds,

--

Peneluc

[Bruno DAléssio]

Sinceramente não consegui identificar essa "multiplicação dos métodos" no modelo dele,
metódos de ByPass em camada de abstração creio ser normal e não é de fato uma replicação.

Posso estar errado, mais estamos aqui para isso, conversar e para aprender.

Abs,

2009/11/30 Vinicius Quaiato <vinicius...@gmail.com>

[Peneluc]

Olá Vinicius,

>>Eu diria que essa "multiplicação dos métodos" se dá em arquiteturas/códigos mal feitas. Onde você tem responsabilidades >>demais em uma classe/método e desta forma não sabe onde estão as coisas que deveria estar em um único lugar.

Então, em qual arquitetura evitamos que os "indisciplinados" construam métodos fora do modelo? Como evitar isso?
Acho que isso tem mais haver com o modelo de desenvolvimento, mas vamos lá... Por exemplo:
Existem casos do Usuário criar "buscarUsuario(BEUsuario be)" e "buscarUsuarioPorID(int ID)"

>>Sobre a migração para o MVC eu diria que, se nos webforms você não tiver nenhum, ou quase nada, de processamento >>específico de código, isto é, chamadas para o banco, validações de negócio, etc, sua migração pode ser bem simples. Claro >>que isso também irá depender da quantidade dos server controls que você usa/depende.

Isso é uma boa notícia, pois nessa estrutura eu tenho quase ou nenhum código desse tipo na apresentação.
Até os Javascripts coloco em classes para registrar em runtime (não sei se soube explicar), podem ser reaproveitados.

Obrigado Vinicius,

Peneluc

2009/11/30 Vinicius Quaiato <vinicius...@gmail.com>

Eu diria que essa "multiplicação dos métodos" se dá em arquiteturas/códigos mal feitas. Onde você tem responsabilidades demais em uma classe/método e desta forma não sabe onde estão as coisas que deveria estar em um único lugar.

--

Peneluc

[Emmanuel G. Brandão]

Não é uma questão de problema, vai funcionar dessa maneira.

Porém você terá duplicação de código, existirá duas classes que teriam a mesma função mas estão divididas! Você vai perceber que o seu código de validação vai vazar para a camada de interface, e por aí vai... Cheguei a comentar sobre isso no meu blog.

Tente juntar essas duas, e quanto a trabalhar com NH sem problema algum, eu trabalhei com modelo rico (comportamento mais dados na classe de domínio) e usando o NH.

Faça uma PoC juntando os dois e perceba a diferença, para melhor, de se trabalhar com modelos ricos!

[Vinicius Quaiato]

Oi Bruno.
Eu não disse que a arquitetura dele tem problemas, comentei sobre o ponto que ele levantou:

"Por exemplo, observei que
em projetos grandes, com diversos desenvolvedores "indisciplinados" **,

** São aqueles que "passam o olho" no Diagrama de Seqüência e
escrevem seus próprios métodos, não reaproveitam, etc. No caso,
específico, os desenvolvedores não buscam nos BMs as referências
ao repositório e recriam estas chamadas em diversos BMs ou até no
mesmo com outro nome."

 

Peneluc,
Uma forma de impedir que os desenvolvedores façam isso é ter camadas bem específicas, e classes com responsabilidades bem claras e métodos bem definidos.
Evitar de ter métodos com mais de uma responsabilidade, pois quem escreveu pode entender que ele faz essas coisas e como faz, mas quem está lendo não entende, acha complicado entender e escreve novamente.

Se você seguir alguns princípios de design orientado a objetos(princípio da responsabilidade única, inversão de dependência, etc) terá sucesso nessa tarefa.

Outra dica é ter uma equipe que, acima de tudo, se comunica. É importante que os desenvolvedores conversem sobre o que estão fazendo. Mostrem aos outros o que implementaram. Se for possível, programação em par para algumas tarefas é bastante interessante.

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Google Talk: vinicius.quaiato

Twitter

--- @ WiseStamp Signature. Get it now

2009/11/30 Bruno DAléssio <bruno...@gmail.com>

[Bruno DAléssio]

Perfeito Vinicius.

Peneluc, vou apenas reforçar 2 (dois) pontos já levantados pelo Vinicius.

1 - Camadas bem específicas e classes com responsabilidades bem claras.
Pense nisso com muito carinho, creio eu, que isso é fundamental em qualquer arquitetura.

2- Comunicação.
Já vi alguns projetos (e não foram projetos pequenos não, gigantes mesmo) afundarem por falta de comunicação.
Fora que, mesmo com tudo bem definido, lindo e maravilhoso, a falta de comunicação gera repetição de funcionalidades,
e diversos outros estresses desnecessários.
E tambem este ponto, seja o principal desafio de qualquer projeto.


Valeu!

2009/11/30 Vinicius Quaiato <vinicius...@gmail.com>

[Peneluc]

Saquei Emmanuel,

Acho que posso realmente unir as duas, mas não quis colcocar mais
esta função para o BP.

O meu BP tem a função de armazenar apenas a Regra de Negócio.

O BM centraliza as chamadas para as camadas de Persistência.
Por exemplo, se estiver usando o NHibernate falo com Persistence.NH,
mas se tiver usando a camada DALC falo com Persistence.Dalc.


Agora, já o lance de usar as classes do NH me deixava preocupado.

1. Usar as classes com os bags e os relacionamentos carregados sendo
transportados entre as camadas (mesmo usando o lazy, alguns sempre vão).
Outro dilema:
Criar ou não objetos de transferência?

2. Isso deixava minhas entidades sem validação de valores na sua criação.
Porque se eu validasse toda entidade instanciada antes de ser passada como
parâmetro em um método, o sistema pararia.
De novo:
Criar ou não objetos de transferência?

Por isso, preferi usar as classes do NH.

Valeu,

--

Peneluc

[Felipe Borges]

Peneluc,

Só seguindo a ideia do Vinicius e do Bruno quanto a responsabilidades claras para as classes e métodos, tem um artigo muito interessante que me ajudou tambem, esclarece varios pontos:
Sao 3 artigos:
http://rodbv.wordpress.com/2009/01/03/em-busca-de-uma-arquitetura-solida/

Espero que te ajude.

[]'s

2009/11/30 Felipe Borges <felipe...@gmail.com>

Peneluc,

Só seguindo a ideia do Vinicius e do Bruno quanto a responsabilidades claras para as classes e métodos, tem um artigo muito interessante que me ajudou tambem, esclarece varios pontos:
Sao 3 artigos:
http://rodbv.wordpress.com/2009/01/03/em-busca-de-uma-arquitetura-solida/

Espero que te ajude.

[]'s

2009/11/30 Peneluc <pen...@gmail.com>

--
PRABOR - Software Development - fel...@prabor.com.br
----------------------------------------------------------------
Felipe Prata L. Borges
MCT, MCPD .Net Framework 2.0: Web Applications
Contact: +55 19 9356 1355
msn: felip...@hotmail.com
skype: felipe.prabor

--
PRABOR - Software Development - fel...@prabor.com.br
----------------------------------------------------------------
Felipe Prata L. Borges
MCT, MCPD .Net Framework 2.0: Web Applications
Contact: +55 19 9356 1355
msn: felip...@hotmail.com
skype: felipe.prabor

[Emmanuel G. Brandão]

Mas você não terá mais esse monte de camadas! Veja, terá a camada de interface e de domínio, o resto será sua infra, que é o NH, a validação estará nas classes de domínio... 

Eu estou fazendo uma sequência de postes no meu blog sobre isso, no momento uso Enterprise Library, depois vou implementar o NH pra ver a diferença, mas ele já esta no modelo rico.

[Peneluc]

Emmanuel,

Você lembra o primeiro post da série e o nome?

--

Peneluc

[Emmanuel G. Brandão]

Tá na mão... http://egomesbrandao.net/blog/category/abcapp/

Vai de baixo pra cima... Qq coisa comenta lá!

[Peneluc]

OK, valeu!

--

Peneluc