none
Pesquisa RRS feed

  • Pergunta

  • Galera estou tentando montar uma arquitetura ideal para meus sistemas.

    Uma das arquiteturas é a seguinte:

     

    Form,Processo,Entidade,Negocio,Acesso a Dados

     

    Cada uma dessas seria uma camada

     

    A outra forma é ter a Entidade dentro da Negócio.

    O que vcs acham disso e qual é a melhor?

     

    Obrigado

     

    quarta-feira, 18 de julho de 2007 23:11

Respostas

  • Oi !

     

    A arquitetura ideal é a arquitetura flexivel, que não fica rígida em um formato como sendo a arquitetura ideal.

     

    Veja este vídeo : http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=pt-BR&EventID=1032341963&CountryCode=BR

     

    []'s

     

    quinta-feira, 19 de julho de 2007 05:56
  • Boas,

     

    Se vc estiver levando em consideração o conceito de camadas e OOP, então eu mudaria um pouco a ordem das camadas:

    Form(UI): Apenas Telas pra resgatar e motrar informação;

    Negócio(BLL): Toda a inteligência da aplicação. Não entendi muito o que vc quis dizer colocando uma camada de Processo na sua estrutura acima, mas acredito que ela deva se encaixar aqui também;

    Acesso a Dados(DAL): Somente essa camada acessa dados, as Entidades, como são tb objetos de dados estarão inclusas aqui também.

     

    Acredito que assim vc terá uma estrutura bastante facil de se trabalhar, reutilizável e bastante flexível.

    terça-feira, 24 de julho de 2007 18:12
  • Lembrando que você pode ter também uma camada de workflow e colocar parte da regra de negócios nela.
    quarta-feira, 25 de julho de 2007 14:58
  •  

    É possível implementar das duas formas, mas existem vantagens e limitações em cada uma, como sempre Smile

     

    Separando totalmente a entidade, que passa a ser um container de dados tem vantagens:

    - Você tem um DTO (Data Transfer Object) leve para transferir pelas camadas da aplicação (bom para arquiteturas distribuídas)

    - É possível utilizar estas entidades em databindings em formulários

     

    Classes de negócio que também são entidades encapsulam melhor. Porém existe um problema: Nem todas as regras de negócios se restringem a uma entidade. Neste caso de quem é a responsabilidade? Muitas vezes é necessário implementar estas transações em classes de negócios "não entidades", tenha isto em mente.

     

    Eduardo Miranda

    www.eduardomiranda.net/blogs/dotnet/

     

    quarta-feira, 25 de julho de 2007 21:33
  • No meu ponto de vista, arquitetura ideal é uma arquitetura que permita que seu sistema siga as seguintes premissas:

    Baixo Acoplamento
    Alta Coesão

    Eu prefiro modelar a Entidade e Negócio juntos, assim temos as entidades de negócio com seus atributos e métodos e o modelagem fica altamente coesa. Quando separamos a entidade do negócio, eu acho que criamos camadas desnecessárias.

    Existe um Anti-Pattern chamado Anemic Domain Model que explica exatamente isso, é bom dar uma lida e tirar a sua conclusão.

    http://martinfowler.com/bliki/AnemicDomainModel.html

    Além disso, eu gosto muito de utilizar o Pattern DAO,

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

    A idéia é bem interessante para que as operações de persistencia de dados e regras de negócio fiquem pouco acopladas.

    Mas isso varia para cada caso, quem tem que tirar as conclusões sobre o que é melhor é você, pois isso tem que estar bem alinhado com os objetivos do projeto em que você vai utilizar.



    Espero ter ajudado
    Fernando Filiputti

    quinta-feira, 26 de julho de 2007 14:33

Todas as Respostas

  • Oi !

     

    A arquitetura ideal é a arquitetura flexivel, que não fica rígida em um formato como sendo a arquitetura ideal.

     

    Veja este vídeo : http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=pt-BR&EventID=1032341963&CountryCode=BR

     

    []'s

     

    quinta-feira, 19 de julho de 2007 05:56
  • Boas,

     

    Se vc estiver levando em consideração o conceito de camadas e OOP, então eu mudaria um pouco a ordem das camadas:

    Form(UI): Apenas Telas pra resgatar e motrar informação;

    Negócio(BLL): Toda a inteligência da aplicação. Não entendi muito o que vc quis dizer colocando uma camada de Processo na sua estrutura acima, mas acredito que ela deva se encaixar aqui também;

    Acesso a Dados(DAL): Somente essa camada acessa dados, as Entidades, como são tb objetos de dados estarão inclusas aqui também.

     

    Acredito que assim vc terá uma estrutura bastante facil de se trabalhar, reutilizável e bastante flexível.

    terça-feira, 24 de julho de 2007 18:12
  • Lembrando que você pode ter também uma camada de workflow e colocar parte da regra de negócios nela.
    quarta-feira, 25 de julho de 2007 14:58
  •  

    É possível implementar das duas formas, mas existem vantagens e limitações em cada uma, como sempre Smile

     

    Separando totalmente a entidade, que passa a ser um container de dados tem vantagens:

    - Você tem um DTO (Data Transfer Object) leve para transferir pelas camadas da aplicação (bom para arquiteturas distribuídas)

    - É possível utilizar estas entidades em databindings em formulários

     

    Classes de negócio que também são entidades encapsulam melhor. Porém existe um problema: Nem todas as regras de negócios se restringem a uma entidade. Neste caso de quem é a responsabilidade? Muitas vezes é necessário implementar estas transações em classes de negócios "não entidades", tenha isto em mente.

     

    Eduardo Miranda

    www.eduardomiranda.net/blogs/dotnet/

     

    quarta-feira, 25 de julho de 2007 21:33
  • No meu ponto de vista, arquitetura ideal é uma arquitetura que permita que seu sistema siga as seguintes premissas:

    Baixo Acoplamento
    Alta Coesão

    Eu prefiro modelar a Entidade e Negócio juntos, assim temos as entidades de negócio com seus atributos e métodos e o modelagem fica altamente coesa. Quando separamos a entidade do negócio, eu acho que criamos camadas desnecessárias.

    Existe um Anti-Pattern chamado Anemic Domain Model que explica exatamente isso, é bom dar uma lida e tirar a sua conclusão.

    http://martinfowler.com/bliki/AnemicDomainModel.html

    Além disso, eu gosto muito de utilizar o Pattern DAO,

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

    A idéia é bem interessante para que as operações de persistencia de dados e regras de negócio fiquem pouco acopladas.

    Mas isso varia para cada caso, quem tem que tirar as conclusões sobre o que é melhor é você, pois isso tem que estar bem alinhado com os objetivos do projeto em que você vai utilizar.



    Espero ter ajudado
    Fernando Filiputti

    quinta-feira, 26 de julho de 2007 14:33