Pesquisa

Question

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

 

Answer 1

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

 

Answer 2

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.

Answer 3

Lembrando que você pode ter também uma camada de workflow e colocar parte da regra de negócios nela.

Answer 4

 

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

 

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/

 

Answer 5

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