none
Design Pattern RRS feed

  • Pergunta

  • Bom dia pessoal,

    Qual seria o melhor pattern a ser aplicado para uma aplicação que rodará no modo client e web ? Estou pensando em adotar Façade + DAO, o que vcs acham ?

    []´s
    Fernando
    quinta-feira, 22 de fevereiro de 2007 13:01

Respostas

  • Felipe,

    Os padroes estao especificados para resolverem problemas determinados e ajudar a escrever codigos mais claros. Computacionalmente falando, voce está informando o resultado da receita e pedindo qual a melhor receita para chegar neste objetivo. Que podem ser muitas, entao dependende de outros fatores, pecas e componentes transversais a sua arquitetura e produto. Assim que, o contexto de uso é importante para uma analise melhor e descobrir uma solucao mais adequada.

    Os padroes que voce comenta, e como respondido acima, sao fundamentais que em qualquer solucao, mas apesar disso nao responde a outras necessidades que irao surgir. O facade (GOF), Wrapper Facade (POSA 2), é ideal quando queremos encapsular caracteristicas do sistema e deixar o programador mais longe de alguns detalhes da implementacao, isto significa, adotar aos subsistemas de seu produto uma interface de acesso analoga. Quanto acesso, persistencia e integracao dos dados, existem mil alteranativas , e como arquiteto voce deve procurar utilizar a que melhor responsada as necessidades e requisitos funcionais e nao funcionais. Deve estar claro a separacao de sua responsabilidade, assim como outras, e que este nao tem comportamento, apenas guarda as entidades na base de dados.

    De uma olhada nos Applications Block da MS e veja como eles podem ajudar a resolver as questoes transversais ao seu negocio. Uma boa literatura é POSA e Application Architecture for .NET.

    abs

    FC

    http://sushinetcode.blogdrive.com

    sexta-feira, 23 de fevereiro de 2007 12:18
  • Fernando,

    Como todo mundo já disse, não existe uma resposta determinisca para design de software. Existem diversas soluções, cada um com vantagens e desvantagens. Você terá que pensar nos principais requisitos e escolher uma. O Joel Spolsky afirma que software design is a one man job, ou seja, você deve adquirir o máximo de informação possível com diversas pessoas, mas vai ter uma hora que você terá que sentar e definir como será sua arquitetura.

    Pela sua pergunta, me parece que você ainda não pensou/descobriu todos requisitos ainda. É importante entender o problema antes de buscar a solução. Algumas perguntas válidas:

    • Como será distribuída fisicamente a solução?
    • Quantos módulos terão? Eles devem falar entre sí?
    • Os clientes web e winforms atenderão as mesmas funcionalidades? Serão parecidos ou espera-se uma interface mais rica no cliente winform?

    Para resolver o único requisito que ficou mais claro (a aplicação deve ter interfaces Web e Winforms) sugiro que você estude o design pattern Model View Presenter (MVP). Ele pode ser considerado uma "aplicação" do facade, mas bem específico para isolar totalmente a UI do seu comportamento. Seguem alguns links:

    http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx

    http://www.codeproject.com/useritems/ModelViewPresenter.asp

    http://www.codeproject.com/useritems/MVP.asp

    http://codebetter.com/blogs/jeremy.miller/archive/2006/02/01/137457.aspx

    Boa sorte,

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

    sábado, 3 de março de 2007 16:11

Todas as Respostas

  • É difícil dizer que se você usar esses patterns você vai ter mais sucesso do que não usar. Você conhece esses patterns? se sim, eles atendem sua necessidade? se sim, use! Não utilize design pattern simplesmente por usar. O que posso te dizer a respeito da sua pergunta é que o Facade vai lher dar uma flexibilidade no que diz respeito a UI (que no seu caso será útil) e quanto ao DAO, te aconselho a usar o DAAB que implementa isso pra você.
    quinta-feira, 22 de fevereiro de 2007 19:49
  • Quanto ao Façade, ele é o mais recomendado para dar flexibilidade de interfaces, certo ?

    Quanto ao DAAB eu já olhei, porém minha aplicação não permitirá o uso DAAB, precisarei implementar o DAO mesmo, que pelo que vi, me atenderá.

    Valeu pela ajuda.

    []s


    quinta-feira, 22 de fevereiro de 2007 20:28
  • Facade não é bem para isso, mas resolve isso também. Na verdade ele provê uma interace unificada e até amigável para quem vai desenvolver a UI ou outra camada tambem, por exemplo abstraindo chamadas a varios métodos de vários componentes para uma única chamada de método na facade.
    quinta-feira, 22 de fevereiro de 2007 20:38
  • Aproveitando então, qual pattern seria o mais recomendado para a minha necessidade ?

    []´s
    sexta-feira, 23 de fevereiro de 2007 01:08
  • Felipe,

    Os padroes estao especificados para resolverem problemas determinados e ajudar a escrever codigos mais claros. Computacionalmente falando, voce está informando o resultado da receita e pedindo qual a melhor receita para chegar neste objetivo. Que podem ser muitas, entao dependende de outros fatores, pecas e componentes transversais a sua arquitetura e produto. Assim que, o contexto de uso é importante para uma analise melhor e descobrir uma solucao mais adequada.

    Os padroes que voce comenta, e como respondido acima, sao fundamentais que em qualquer solucao, mas apesar disso nao responde a outras necessidades que irao surgir. O facade (GOF), Wrapper Facade (POSA 2), é ideal quando queremos encapsular caracteristicas do sistema e deixar o programador mais longe de alguns detalhes da implementacao, isto significa, adotar aos subsistemas de seu produto uma interface de acesso analoga. Quanto acesso, persistencia e integracao dos dados, existem mil alteranativas , e como arquiteto voce deve procurar utilizar a que melhor responsada as necessidades e requisitos funcionais e nao funcionais. Deve estar claro a separacao de sua responsabilidade, assim como outras, e que este nao tem comportamento, apenas guarda as entidades na base de dados.

    De uma olhada nos Applications Block da MS e veja como eles podem ajudar a resolver as questoes transversais ao seu negocio. Uma boa literatura é POSA e Application Architecture for .NET.

    abs

    FC

    http://sushinetcode.blogdrive.com

    sexta-feira, 23 de fevereiro de 2007 12:18
  • Bem, como eu disse na primeira resposta, você conhece os detalhes das suas necessidades melhor do que ninguem. Mas posso lhe dizer que o DAO é normalmente interessante usa-lo. Quanto ao Facade, como a necessidade que você passou é em relação a interface, ele vai lhe ajudar em relação a simplificação de acesso a segunda camada da sua aplicação, não vejo por que não usar.
    sexta-feira, 23 de fevereiro de 2007 12:36
  • Com relação ao uso do Facade no contexto que o pessoal expos existem diversas vantagens, no entanto do meu ponto de vista em determinados projetos e prazos é algo complicado de se implementar porque cada interface de apresentação (página aspx) terá que ter seu próprio facade pra poder unificar as chamadas as outras camadas e isso demanda um tempo relativamente alto.

    Att.,
    Antonio Carlos

    sábado, 24 de fevereiro de 2007 15:53
  • Não necessáriamente, você pode implementar facade como interface para os servicos da regra de negocio independente da UI.
    domingo, 25 de fevereiro de 2007 16:22
  • De que modo seria feito dessa forma que você sugere? Até onde eu conheço implementação do modelo de Facade iriamos ter uma classe para cada tela que tivesse regra de negócio diferente, pois todas as chamadas a camada de negócios e adjacentes seriam feitas nessa classe, dessa forma unificando o acesso as camadas "abaixo" da apresentação.

    Correto?

    Att.,
    Antonio Carlos

    segunda-feira, 26 de fevereiro de 2007 14:15
  • Correto, mas você tem que abstrair a UI, pense em simplificar o acesso à regra de negócio. Dessa forma, você não teria necessáriamente uma classe facade para cada tela, e sim para funcionalidade da regra de negocio, onde se não existisse facade você iria chamar 4 métodos e com facade você chama apenas um.
    segunda-feira, 26 de fevereiro de 2007 14:27
  • Fernando,

    Como todo mundo já disse, não existe uma resposta determinisca para design de software. Existem diversas soluções, cada um com vantagens e desvantagens. Você terá que pensar nos principais requisitos e escolher uma. O Joel Spolsky afirma que software design is a one man job, ou seja, você deve adquirir o máximo de informação possível com diversas pessoas, mas vai ter uma hora que você terá que sentar e definir como será sua arquitetura.

    Pela sua pergunta, me parece que você ainda não pensou/descobriu todos requisitos ainda. É importante entender o problema antes de buscar a solução. Algumas perguntas válidas:

    • Como será distribuída fisicamente a solução?
    • Quantos módulos terão? Eles devem falar entre sí?
    • Os clientes web e winforms atenderão as mesmas funcionalidades? Serão parecidos ou espera-se uma interface mais rica no cliente winform?

    Para resolver o único requisito que ficou mais claro (a aplicação deve ter interfaces Web e Winforms) sugiro que você estude o design pattern Model View Presenter (MVP). Ele pode ser considerado uma "aplicação" do facade, mas bem específico para isolar totalmente a UI do seu comportamento. Seguem alguns links:

    http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx

    http://www.codeproject.com/useritems/ModelViewPresenter.asp

    http://www.codeproject.com/useritems/MVP.asp

    http://codebetter.com/blogs/jeremy.miller/archive/2006/02/01/137457.aspx

    Boa sorte,

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

    sábado, 3 de março de 2007 16:11
  • Eduardo,

    Eu acho que vc trocou os nomes. Mas complementando sua resposta eu sugeriria outros padrões também além do MVP a todos que estao acompanhando a ferramentas disponibilizadas pelo pessoal do p&p: Dependency Injection, Service Locator e Controller. Além disso vale uma leitura detalhada do Composite Application Block que é o coracão do Web Client Software Factory liberado este mes.

     

    abs a todos

    FC

    http://sushinetcode.blogdrive.com

     

     

    segunda-feira, 5 de março de 2007 02:50
  • Não confundi, os nomes são iguais. Quem iniciou a thread foi FFeliu (Fernando), estava respondendo para ele.

    Mas, mais uma vez, um design pattern só faz sentido se resolve um problema, um requisito. Por exemplo, o Depency Injection é um ótimo pattern para quem está buscando diminuir acoplamento entre camadas e classes. Não sabemos se o Fernando tem este problema, pois a pergunta dele foi muito genérica. Por isto o mais importante é que ele identifique as necessidades do sistema, para depois buscar as soluções.

     

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

     


     

    segunda-feira, 5 de março de 2007 16:11
  • Ola Fernando,

    Primeiramente não tem como definirmos os padrões que serão utilizados sem termos o Modelo de Dominio da sua aplicação.

    Bom o interessante seria estudar bem os padrões, por exemplo o facade que vc sitou por ser um padrao estrutural pode ser usado em quase tudo.

    Se quiser conversar mais e ler mais sobre assunto curte a minha Page e me acompanhe lá no meu Blog:

    Blog Arquiteto.Net

    Page Arquiteto.Net

    Entra lá e qq duvida pode conversar diretamente comigo.


    quarta-feira, 5 de dezembro de 2012 03:26