none
Camadas ... RRS feed

  • Pergunta

  •  

    Olá amigos,

    Estou com algumas duvidas de como trabalhar em camadas...

    VISUAL STUDIO 2005 - ASP.NET 2.0 - C#

    Imaginar um sistema : Um cliente solicita um site que de inicio vai ter, cadastro de Produtos, listagem, alteração etc e cadastro de Clientes.

    Abro um projeto : "VendasCerto.com.br"

    Dai crio as pastas :

    App_Code/

    App_Code/DTO - aqui eu crio uma Class: ProdutoDTO.cs e ClienteDTO.cs

    * camada de propriedades / atributos

    App_Code/DAL - aqui eu crio Class : Produto.DAL.cs e ClienteDAL.cs

    * Camada acima de acesso ao banco

    App_Code/BLL - aqui : ProdutoBLL.cs e ClienteBLL.cs

    * camada de negocio

    Pronto pessoal, agora vamas ao arquivos da camada de apresentação:

    1. Protudo.aspx - Produto.aspx.cs

    * Acima é onde eu listo os Produtos.

    2. Cliente.aspx - Cliente.aspx.cs

    * Aicma onde listo os clientes.

     

    Então no Produto.aspx.cs eu crio um objeto da camada de negocio (ProdutoBLL.cs) para acessar o metodo especifico .

    Na camada de Negocio ProdutoBLL.cs por sua vez se relaciona com a camda de acesso banco ProdutoDAL.cs para assim fazer os dataset ou SqlDataReader ...

    E assim da mesma forma com o Cliente .

    Está forma de trabalhar com 3 camadas está errado ? poderia ser melhor, como então ??

     

    Abraço e grato pela atenção !

     

     

    segunda-feira, 29 de janeiro de 2007 13:29

Respostas

  • Em arquitetura de sistemas fica difícil usar termos como "certo" ou "errado". Funciona? Resolve seu problema? Então ta bom.

     

    Com certeza tem outras mil formas de fazer. Acho que a recomendação que eu te faria seria olhar os geradores de código que existem por aí, tipo codesmith e outros, e as bibliotecas de templates para eles, como o NetTiers.

     

    Isso porque eles já implementam todas essas coisas e vão evitar que você faça tudo na mão...

    segunda-feira, 29 de janeiro de 2007 20:59
  • Estimados:

    Acredito que o buraco é mais em baixo. Veja bem: a ferramenta vs.net cria estas pastas para ajudar a separar as responsabilidades, mas nao significa que essa seja a melhor maneira. Exitem outros fatores e alguns casos onde BL e o DAL podem até ser um projeto de referencia desagregado do atual para permitir um melhor desacoplamento. Outra coisa é que você deve levar em consideracao é a performance para o mapeamento das entidades e outros objetos. Uma dica é que as capas deveriam comunicar-se apenas com suas vizinhas, mas algums casos,  excecoes são válidas.

    Outro detalhe que deve também ser levado em consideracao: separar a regra de logica da aplicacao dos aspectos transversais: auditoria, seguranca, tratamento de excecoes...

    Bem, em resumo, para saber se vai le servir a solucao, é necessário avaliar o que você precisa resolver, quais os requisitos funcionais e arquitetonicos que voce tem que responder.

    QQ duvida me escreva

    Abs

    FC

    sushinetcode.blogdrive.com

    sábado, 3 de fevereiro de 2007 03:58
  • Luis,

    Analisando o que você escreveu, eu te daria uma dica: Se você está utilizando o DTO (Data Transfer Objects) pattern, a sua camada DAL deveria sempre se comunicar com a camadas de negócios através de objetos DTO, nunca através de datasets ou datareaders.

    O ideal é que as outras camadas não tivessem conhecimento da biblioteca System.data. Qualquer referência a esta biblioteca deve ser considera um code smell. É lógico que o bom senso deve sempre persistir, não devemos nunca tomar uma regra como totalmente inviolável.

    Eduardo Miranda
    SDE - Microsoft - GDL Latam
    www.eduardomiranda.net/blogs/dotnet

     

    sábado, 3 de março de 2007 17:00

Todas as Respostas

  • Em arquitetura de sistemas fica difícil usar termos como "certo" ou "errado". Funciona? Resolve seu problema? Então ta bom.

     

    Com certeza tem outras mil formas de fazer. Acho que a recomendação que eu te faria seria olhar os geradores de código que existem por aí, tipo codesmith e outros, e as bibliotecas de templates para eles, como o NetTiers.

     

    Isso porque eles já implementam todas essas coisas e vão evitar que você faça tudo na mão...

    segunda-feira, 29 de janeiro de 2007 20:59
  • Estimados:

    Acredito que o buraco é mais em baixo. Veja bem: a ferramenta vs.net cria estas pastas para ajudar a separar as responsabilidades, mas nao significa que essa seja a melhor maneira. Exitem outros fatores e alguns casos onde BL e o DAL podem até ser um projeto de referencia desagregado do atual para permitir um melhor desacoplamento. Outra coisa é que você deve levar em consideracao é a performance para o mapeamento das entidades e outros objetos. Uma dica é que as capas deveriam comunicar-se apenas com suas vizinhas, mas algums casos,  excecoes são válidas.

    Outro detalhe que deve também ser levado em consideracao: separar a regra de logica da aplicacao dos aspectos transversais: auditoria, seguranca, tratamento de excecoes...

    Bem, em resumo, para saber se vai le servir a solucao, é necessário avaliar o que você precisa resolver, quais os requisitos funcionais e arquitetonicos que voce tem que responder.

    QQ duvida me escreva

    Abs

    FC

    sushinetcode.blogdrive.com

    sábado, 3 de fevereiro de 2007 03:58
  • Fernando,

    Gostei dos aspectos transversais.
    Isso é bastante importante de se pensar e executar, mas complicado para  o começo.

    Recomendo nosso amigo começar com as coisas mais simples!
    E ir evoluindo! E em uma próxima fase chegar nos aspectos!

    [ ]'s

    quinta-feira, 1 de março de 2007 18:26
  • Luis,

    Analisando o que você escreveu, eu te daria uma dica: Se você está utilizando o DTO (Data Transfer Objects) pattern, a sua camada DAL deveria sempre se comunicar com a camadas de negócios através de objetos DTO, nunca através de datasets ou datareaders.

    O ideal é que as outras camadas não tivessem conhecimento da biblioteca System.data. Qualquer referência a esta biblioteca deve ser considera um code smell. É lógico que o bom senso deve sempre persistir, não devemos nunca tomar uma regra como totalmente inviolável.

    Eduardo Miranda
    SDE - Microsoft - GDL Latam
    www.eduardomiranda.net/blogs/dotnet

     

    sábado, 3 de março de 2007 17:00
  • Gostei dessa do code smell :)
    sexta-feira, 9 de março de 2007 00:28
  • Ainda bem que ainda não usamos smell devices, senão ia ter código impossível de trabalhar...

     

    Eduardo Miranda
    SDE - GDL Latam - Microsoft
    http://eduardomiranda.net/blogs/dotnet

    segunda-feira, 12 de março de 2007 19:44
  • Tudo estava indo tão bem....

    Eduardo você comenta sobre o fato da camada de negócios evitar a utilização de dados (system.data) o que pra mim faz todo sentido do mundo. Mais imaginando a situação de que preciso popular uma gridview eu efetuo esse processo da seguinte forma:

    No page-load da grid chamo um método de popular grid que se encontra na minha camada de negócios, essa por sua vez irá receber os parâmetros necessário, validar informações, montar a query e enviar para a camada de Dados executar. A camada de dados me retornar um conjunto de dados que é recebido pela camada de negócio que então popula a grid.

    Neste processo como deixar a camada de negócio não enchergar o que a camada de dados me retornou? Teria que transformar o datareader/dataset/datatable em alguma outra coisa? Derrepente dizer diretamente que gv.datasource = CamadaNegocio.recuperaPedidos().

    Como vocês fariam esse processo para que houvesse a melhor serparação das camadas?

    Agradeço a atenção.

    sexta-feira, 16 de março de 2007 13:23
  • Cara,

     

    Existe uma forma muito simples de resolver isto, mantendo uma arquitetura mais parecida possível com a que você descreveu. O GridView aceita objetos como data sources. Portanto você poderia implementar uma classe Customer, uma coleção “stronged typed” Customers e implementar a CustomerBS ou CustomerServices, dependendo do pattern utilizado. Esta última classe implementa os métodos para buscar, inserir, alterar e apagar um customer.

     

    Pronto, você tem sua camada de interface totalmente livre do System.Data. Não foi tão simples como você esperava? Concordo, existe um custo para implementar soluções com baixo acoplamento entre as camadas. O benefício depende muito do escopo do projeto que você está trabalhando. É um software para minha avó cadastrar suas receitas? Ou é um aplicativo empresarial que exigirá manutenção e evolução constante? Ai vai o bom sendo do arquiteto/desenvolvedor.

     

    Uma coisa é importante ter em mente: Quantas API de acesso a dados você já trabalhou durante sua vida de desenvolvedor? Se vc começou no ASP, duas: ADO e ADO.Net. Se você é um pouco mais "experiente" usou DAO, e por ai vai (não vou continuar para não mostrar toda a minha "experiência" ). Você já ouviu falar de Linq, então já sabe que daqui a pouco teremos outro modelo de acesso a dados disponível. O ponto aqui é: quando lidamos com uma tecnologia tão volátil, devemos sempre pensar em isolá-la. Se você não fizer isto daqui a dois anos o seu software vai estar totalmente defasado e o custo de atualizá-lo será proibitivo.

     

    Espero ter ajudado

     

    Eduardo Miranda

    http://eduardomiranda.net/blog/dotnet

     

    sábado, 17 de março de 2007 00:22
  • Pessoal,

    Coloquei um post no meu blog falando um pouco mais sobre este assunto:

    http://eduardomiranda.net/blogs/dotnet/archive/2007/03/18/isolando-camadas-da-aplica-o.aspx

     

    Eduardo Miranda
    http://eduardomiranda.net/blogs/dotnet

    domingo, 18 de março de 2007 18:55