Aplicação web em 5 camadas

Olá pessoal, estou olhando separação de camadas ultimamente sempre que posso, já que não última vez que perguntei aqui parece que fiz uma mistureba de conceitos que gerou uma guerra entre usuário aqui no forum rs.

Básicamente o que entendi é que para uma aplicação simples(que é o que eu pretendo fazer) são suficientes 5 camadas.

Cliente - que é basicamente o que o cliente verá em sua tela(no meu caso as páginas jsf/xhtml e arquivos css)
Apresentação - regras de navegação e validações de tela(No meu caso seriam meus ManagedBeans)
Negócio - Aqui ficam minhas entidades/minha regras de negócio(Não tenho certeza ainda se em uma aplicação pequena vale a pena utilizar Spring aqui)
Integração(no meu caso persistência) - é aonde o java é integrado a camada de recursos(no meu caso, hibernate)
Recursos - Dados brutos(no meu caso, um scheme do MySQL)

Aguardo críticas, adendos, vuadoras, etc.
Obrigado.

Cara estude sobre o modelo MVC (Modelo, Visão, Controle).

Modelo - (Suas entidades, regras do negócio);
Visão - (Paginas XHTML, para utilização do usuário);
Controle - (Seus ManagedBeans);

De maneira resumida, acho que é isso.

[quote=douglas_arantes]Cara estude sobre o modelo MVC (Modelo, Visão, Controle).

Modelo - (Suas entidades, regras do negócio);
Visão - (Paginas XHTML, para utilização do usuário);
Controle - (Seus ManagedBeans);

De maneira resumida, acho que é isso.[/quote]

MVC != Camadas… Uma coisa não tem nada a ve com a outra.

Opa!

Não vamos misturar as coisas… O conceito MVC é diferente do conceito de arquitetura emCAMADAS…

Arquitetura em Camadas:
Cada camada é formada por um conjunto de classes com um determinado propósito.

MVC: Já foi conceituado no post do colega…

Ok, pra não ficar “solto”:

MVC é sobre design patterns, de modo simplista e generalista é uma utilização de strategy e observer para a interação de COMPONENTES. Não é sobre camada, e você nem precisa de uma view para utiliza-lo.

[quote=diegosammet][quote=douglas_arantes]Cara estude sobre o modelo MVC (Modelo, Visão, Controle).

Modelo - (Suas entidades, regras do negócio);
Visão - (Paginas XHTML, para utilização do usuário);
Controle - (Seus ManagedBeans);

De maneira resumida, acho que é isso.[/quote]

MVC != Camadas… Uma coisa não tem nada a ve com a outra.[/quote]

Sim, Sim, você esta certo, realmente falei bobeira.

[quote=douglas_arantes][quote=diegosammet][quote=douglas_arantes]Cara estude sobre o modelo MVC (Modelo, Visão, Controle).

Modelo - (Suas entidades, regras do negócio);
Visão - (Paginas XHTML, para utilização do usuário);
Controle - (Seus ManagedBeans);

De maneira resumida, acho que é isso.[/quote]

MVC != Camadas… Uma coisa não tem nada a ve com a outra.[/quote]

Sim, Sim, você esta certo, realmente falei bobeira.[/quote]

olha não ta errado nao… vc pode muito bem separa aplicação em 3 camadas igual mvc nada impede, e existe essa arquitetura…

  • Camada de Apresentação;

  • Camada de Regra de Negócio;

  • Camada de Acesso a Dados.

Vulgo MVC…

essa arquitetura exposta pelo leonardogamba é a de N camadas…

logo o unico que falou bobagem foi o diegosammet.

sem mais a acrescenta…

[quote=darklordkamui][quote=douglas_arantes][quote=diegosammet][quote=douglas_arantes]Cara estude sobre o modelo MVC (Modelo, Visão, Controle).

Modelo - (Suas entidades, regras do negócio);
Visão - (Paginas XHTML, para utilização do usuário);
Controle - (Seus ManagedBeans);

De maneira resumida, acho que é isso.[/quote]

MVC != Camadas… Uma coisa não tem nada a ve com a outra.[/quote]

Sim, Sim, você esta certo, realmente falei bobeira.[/quote]

olha não ta errado nao… vc pode muito bem separa aplicação em 3 camadas igual mvc nada impede, e existe essa arquitetura…

  • Camada de Apresentação;

  • Camada de Regra de Negócio;

  • Camada de Acesso a Dados.

Vulgo MVC…

essa arquitetura exposta pelo leonardogamba é a de N camadas…

logo o unico que falou bobagem foi o diegosammet.

sem mais a acrescenta…

[/quote]

Novamente, MVC não é sobre arquitetura de camadas, é um design pattern sobre interação entre componentes. Fonte: http://shop.oreilly.com/product/9780596007126.do

[quote=darklordkamui][quote=douglas_arantes][quote=diegosammet][quote=douglas_arantes]Cara estude sobre o modelo MVC (Modelo, Visão, Controle).

Modelo - (Suas entidades, regras do negócio);
Visão - (Paginas XHTML, para utilização do usuário);
Controle - (Seus ManagedBeans);

De maneira resumida, acho que é isso.[/quote]

MVC != Camadas… Uma coisa não tem nada a ve com a outra.[/quote]

Sim, Sim, você esta certo, realmente falei bobeira.[/quote]

olha não ta errado nao… vc pode muito bem separa aplicação em 3 camadas igual mvc nada impede, e existe essa arquitetura…

  • Camada de Apresentação;

  • Camada de Regra de Negócio;

  • Camada de Acesso a Dados.

Vulgo MVC…

essa arquitetura exposta pelo leonardogamba é a de N camadas…

logo o unico que falou bobagem foi o diegosammet.

sem mais a acrescenta…
[/quote]

Concordo que MVC e Camadas não é a mesma, mas dizer que não tem nada haver uma coisa com a outra foi um equivoco dele.

E se manja tanto, poderia ter solucionado a dúvida do autor do tópico.

t++;

[quote=darklordkamui][quote=douglas_arantes][quote=diegosammet][quote=douglas_arantes]Cara estude sobre o modelo MVC (Modelo, Visão, Controle).

Modelo - (Suas entidades, regras do negócio);
Visão - (Paginas XHTML, para utilização do usuário);
Controle - (Seus ManagedBeans);

De maneira resumida, acho que é isso.[/quote]

MVC != Camadas… Uma coisa não tem nada a ve com a outra.[/quote]

Sim, Sim, você esta certo, realmente falei bobeira.[/quote]

olha não ta errado nao… vc pode muito bem separa aplicação em 3 camadas igual mvc nada impede, e existe essa arquitetura…

  • Camada de Apresentação;

  • Camada de Regra de Negócio;

  • Camada de Acesso a Dados.

Vulgo MVC…

essa arquitetura exposta pelo leonardogamba é a de N camadas…

logo o unico que falou bobagem foi o diegosammet.

[/quote]

Não. Realmente MVC não é o nome de um conjunto de camadas. É o nome de um design pattern.
Se vc quer usar três camadas, tudo bem. Mas isso não lhe dá a capacidade de inferir que o nome disso é “MVC”. Não. O nome disso é , surpresa , Arquitetura em 3 camadas! :shock:

E o nome das camadas seriam:

Cliente ( Une Client + Apresentação) - não não como não ter o cliente
Dominio (ou Negócio) - “regras de negocio” não é uma camada, porque regras de negocio não são objetos.
Recursos (une Integração e Recursos)

[quote=douglas_arantes][quote=darklordkamui][quote=douglas_arantes][quote=diegosammet][quote=douglas_arantes]Cara estude sobre o modelo MVC (Modelo, Visão, Controle).

Modelo - (Suas entidades, regras do negócio);
Visão - (Paginas XHTML, para utilização do usuário);
Controle - (Seus ManagedBeans);

De maneira resumida, acho que é isso.[/quote]

MVC != Camadas… Uma coisa não tem nada a ve com a outra.[/quote]

Sim, Sim, você esta certo, realmente falei bobeira.[/quote]

olha não ta errado nao… vc pode muito bem separa aplicação em 3 camadas igual mvc nada impede, e existe essa arquitetura…

  • Camada de Apresentação;

  • Camada de Regra de Negócio;

  • Camada de Acesso a Dados.

Vulgo MVC…

essa arquitetura exposta pelo leonardogamba é a de N camadas…

logo o unico que falou bobagem foi o diegosammet.

sem mais a acrescenta…
[/quote]

Concordo que MVC e Camadas não é a mesma, mas dizer que não tem nada haver uma coisa com a outra foi um equivoco dele.

E se manja tanto, poderia ter solucionado a dúvida do autor do tópico.

t++;[/quote]

Não manjo tanto, mas eu tenho certeza do que eu estou falando. Ja que provavelmente vocês não vão ler o livro do O’Reilly que eu postei… Pelo menos leiam esses posts:


[quote=sergiotaborda][quote=darklordkamui][quote=douglas_arantes][quote=diegosammet][quote=douglas_arantes]Cara estude sobre o modelo MVC (Modelo, Visão, Controle).

Modelo - (Suas entidades, regras do negócio);
Visão - (Paginas XHTML, para utilização do usuário);
Controle - (Seus ManagedBeans);

De maneira resumida, acho que é isso.[/quote]

MVC != Camadas… Uma coisa não tem nada a ve com a outra.[/quote]

Sim, Sim, você esta certo, realmente falei bobeira.[/quote]

olha não ta errado nao… vc pode muito bem separa aplicação em 3 camadas igual mvc nada impede, e existe essa arquitetura…

  • Camada de Apresentação;

  • Camada de Regra de Negócio;

  • Camada de Acesso a Dados.

Vulgo MVC…

essa arquitetura exposta pelo leonardogamba é a de N camadas…

logo o unico que falou bobagem foi o diegosammet.

[/quote]

Não. Realmente MVC não é o nome de um conjunto de camadas. É o nome de um design pattern.
Se vc quer usar três camadas, tudo bem. Mas isso não lhe dá a capacidade de inferir que o nome disso é “MVC”. Não. O nome disso é , surpresa , Arquitetura em 3 camadas! :shock:

E o nome das camadas seriam:

Cliente ( Une Client + Apresentação) - não não como não ter o cliente
Dominio (ou Negócio) - “regras de negocio” não é uma camada, porque regras de negocio não são objetos.
Recursos (une Integração e Recursos)

[/quote]

então diga qual é a diferença entre arquitetura 3 camadas e MVC?
se achar diferenças fala ae =D

[quote=leonardogamba]Olá pessoal, estou olhando separação de camadas ultimamente sempre que posso, já que não última vez que perguntei aqui parece que fiz uma mistureba de conceitos que gerou uma guerra entre usuário aqui no forum rs.

Básicamente o que entendi é que para uma aplicação simples(que é o que eu pretendo fazer) são suficientes 5 camadas.

Cliente - que é basicamente o que o cliente verá em sua tela(no meu caso as páginas jsf/xhtml e arquivos css)
[/quote]

Sim, mas o javascript tb entra aqui, e se usar jquery isso tb é cliente

Apresentação não é bem isso. ManagedBeans é de client ( se jsf é client , managed é da mesma camada)
A apresentação tem que ser independente do cliente ( a camada de baixo não vê a de cima). normalmente as pessoas não usam esta camada. e chamam o dominio diratamente do cliente.
Coisas como struts , vraptor etc, estão na camada cliente. É que no caso do web o cliente tem duas “partes”, uma que roda no servidor e outra que roda no browser, mas o servidor tem que enviar para o bowser a parte que roda lá. Tudo isto e´a camada cliente no servidor.
A apresentação deveria ser uma camada que não depende da tecnologia do cliente e que vc pode usar em outros clientes. por exemplo se vc mudar de web para swing, a camada de apresentação ainda deveria ser a mesma. Ela contém as regras de navegação.

As regras de negocio não existem como objetos. Os objetos desta camada são as entidades e objetos de valor associados, os serviços, os validadores e os repositórios (não os daos, temos n threads no forum sobre a diferença) .
Os serviços são por natureza coisas que se compoem (aliás como bons componentes que devem ser). logo se vc não usa JEE com CDI, o Spring é muito util. Ele é muito util em todas as camadas, na realidade, mas especialmente nesta.

Sim, mas a integração é mais que isso. Se vc acessa um File, isso é integração. Se vc acessa um WS é integração. Se vc usa OAuth é integração, etc… integração é sempre que vc precisar de coisas fora da sua VM.
Se vc tiver um mecanismo de upload, por exemplo, vai precisar manipular o arquivo , e de alguma forma colocá-lo no disco, isso é integração. Repare que este código irá correr muito perto do Cliente.
Se vc tiver de enviar email, vc vai querer ter um MailService, esse cara está na camada de integração , sendo acessado pelo Dominio.

Não é bem os dados. É mais o SGBD, os protocolos, a I/O, etc…

[/quote]

As camadas podem ser mais finas ou mais grossas conforme. A de apresentação normalmente é inexistente a menos que haja um grande esforço para isso. A de dominio e cliente serão as maiores.

Existem duas formas de empilhar camadas. Em uma a camada de cima só pode comunicar com a camada imediatamente a seguir. Isto é usado no TCP, por exemplo.
A outra é que a camada de cima pode acessar qualquer camada de baixo. Isto é mais perigoso e pode realmente levar ao conceito de “nenhuma camada”.
O que não pode acontece nunca é a camada de baixo depender da de cima. Isto tb é normalmente muito violado (por exemplo, usando os entibies na camada de integração)

Então, existem trade-offs mais sutis na hora de implementar, e é bom que vc tenha as diretrizes do que vc aceita e não aceita logo à partida, caso contrário é um vale-tudo e a sua ideia de estrutrua se perde.

[quote=sergiotaborda]O que não pode acontece nunca é a camada de baixo depender da de cima. Isto tb é normalmente muito violado (por exemplo, usando os entibies na camada de integração)
[/quote]
Olá sergio obrigado pela resposta, esclareceu algumas coisas mas me surgiu uma dúvida sobre o citado acima.

Se eu faço meu mapeamento ORM direto nas minha entidades da camada de negócio, isso conta como a camada de integração acessando a camada de negócio? Caso seja isso qual a melhor maneira de separar as coisas?

Obrigado.

[quote=leonardogamba][quote=sergiotaborda]O que não pode acontece nunca é a camada de baixo depender da de cima. Isto tb é normalmente muito violado (por exemplo, usando os entibies na camada de integração)
[/quote]
Olá sergio obrigado pela resposta, esclareceu algumas coisas mas me surgiu uma dúvida sobre o citado acima.

Se eu faço meu mapeamento ORM direto nas minha entidades da camada de negócio, isso conta como a camada de integração acessando a camada de negócio? Caso seja isso qual a melhor maneira de separar as coisas?
[/quote]

Conta. Para ver que conta, simule que vai mudar de sistema de persistencia, por exemplo, em vez de hibernate, Spring Data. Vc teria que mudar as entidades ? sim, porque teria que mudar as anotações. Logo, a camada de cima depende da de baixo.
A forma de fazer seria colocar as entidades com anotação (entidades persistentes) na camada de integração. E depois utilizar o repositório da camada de negocio para traduzir. Ou usar objetos genericos como HashMap ( o hibernate tem um jeito de utilizar apenas hashmap, mas não conheço muito bem). Mas , como falei antes, existem trade-offs. Colocar mais indireção significa melhor design, mas mais trabalho. Tal como as pessoas ignoram a camada de apresentação, tb normalmente ignoram essas fronteiras entre as camadas, ou deixam elas serem mais diluídas. O jboss seam , por exemplo, propõe que simplesmente não existam essas fronteiras deixando todas custuradas (seams) umas com as outras.
São este tipo de decisões que irão comandar a sua arquitetura e que no futuro serão dificeis de trocar. Pelo menos não sem um trabalho extra.