Duvida com Camadas

DAO é seu model do MVC, já o JSF é seu view e o hibernate faz parte do controller que processa as requisições feitas na view utilizando as regras do definidas no model, portanto três camadas.

No seu caso, o MODEL sera seu banco de dados, HIBERNATE é
o seu Controller e JSF e’ sua VIEW …

Portanto, 3 camadas.

Não, não.

O JSF faz o papel de view e de controller nesse caso. Hibernate, DAOs, tudo isso pertence ao seu model. O modelo é tudo aquilo que representa o estado da sua aplicação. Porém, com isso não dá pra saber quantas camadas seu sistema possui.

Ultimamente ( graças ao Phillip Calçado ), a seguinte frase tem sido repetida como um mantra aqui no GUJ: MVC != CAMADAS!

Principal fonte: http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas

Abraços

:arrow: :arrow:A língua portuguesa é muito traiçoeira para certas definições. Uma delas é a tradução para “design patterns”, que fica “padrões de projeto”. Na lingua inglesa, “pattern” significa um modelo que se pode segui-lo ou imitá-lo, mas a palavra “padrão”, na nossa língua, está mais próxima de “standard” na língua inglesa, que significa um conjunto de métricas que confere qualidade. Com isso as pessoas encaram “design patterns” como se fosse “design standards”, fazendo com que as pessoas o utilizem demasiadamente achando que com isso se está garantindo qualidade.

Camadas é outra palavra traiçoeira. Tanto “tier” quando “layer” significam camada na nossa língua, porém, tier é uma divisão interprocessos ou intermáquinas, enquanto layer é simplesmente uma divisão lógica no sistema (ou seja, eu posso ter vários layers em um único tier).

Considerando isso acima, posso afirmar com toda certeza que seu sistema tem três tiers: um tier é o browser do usuário, outro tier é o “war” no seu servidor de aplicações, e o último tier é a base de dados.

Entretanto, não posso dizer ao certo quantos layers seu sistema possui, principalmente porque arquitetos adoram subdividir em demasia o tier “do meio”, mas posso lhe dar algumas orientações:

:arrow: Não confunda MVC com camadas (tier ou layer), são coisas meio distintas. No seu caso, a VIEW são as páginas, o CONTROLLER são o faces-config.xml, os managed beans e o servlet que processa requisições Faces, e o MODEL é todo o resto, incluindo DAOs e contexto de persistência.

:arrow: DAO é considerado um layer.

:arrow: O contexto de persistência é algo que é invisível à sua aplicação. Não sei dizer ao certo, mas não o consideraria uma layer.

:arrow: Hibernate não tem nada a ver com controller, ele processa objetos de domínio, ou seja, do model.

É isso.

Excelente explicação do Leonardo3001.

Mto Obrigada pela explicacao pessoal :lol: bjos.

Olá a todos,

pra mim uma camada existe para desempenhar um papel bem definido dentro da aplicação, como por exemplo persistir os objetos de negócio de um sistema, ou realizar a integração com outros sistemas legados, etc. Cada uma dessas camadas pode ser composta por um ou mais componentes que vão trabalhar juntos para atender os objetivos da mesma.

Acredito que a maioria dos sistemas cai naquela definição clássica de 3 camadas: Apresentação, Negócio e Persistência e que eu vejo é que existem muitas tecnologias, frameworks, patterns, etc. para serem utilizados no desenvolvimento das camadas. Struts, JSF, Swing e SWT são exemplos de tecnologias para desenvolvimento da Apresentação, enquanto Hibernate, XStream e TopLink são para a persistência… há inúmeros outros exemplos que se eu for citar vou passar o dia todo :?

Na verdade nem sei o quanto esses conceitos de camadas mudaram/evoluiram… alguém pode comentar sobre esses conceitos que falei ?

Não. DAO é um padrão que vive dentrod a Camada de Persistência.

seuparada como o Leonardo3001 em português a plvr camadas serve para explicar a msm coisa que tier e layer, a diferença entre eles é simples tier são separações fisicas e layer são separações logicas.

ex.: na sua aplicação vc pode ter um servidor de HTTP(ApacheHTTP) para receber as chamadas em um tier um Servidor de Aplicação(Tomcat) q seria nosso segundo tier e um bancoDados em outro servidor separado isso eu chamaria de 3tier um exemplo mais comum é vc desenvolvendo tomcat+banco 2tier que podem estar no msm maquina.

Agora com MVC estamos falando de layer’s inicialmente separamos em três camadas se falarmos da arquitetura/padrão MVC e para por ai 3layer.

Os frameworks em geral fazem a parte Viem e Controller agora o Model é vc que trabalha e ai pode ter N layer na sua aplicação

ex.: na Classe que recebe os parâmetros do JSP(ex. Action do struts uo bean do JSF) vc pode usar um Delegate para acessar os Hibernate/DAO/TopLink/repositorio só ai vc tem 5layer JSP>controler>Action>delegate>percistencia, esse layer são infra-estrutura, dominio do negocio, camadas da aplicação entende…

Resumindo se vc fala de MVC temos três camadas o resto da salada é camadas da aplicação q geralmente estão dentro de model(MVC).

abr

MVC e Camadas são coisas diferentes. MVC não implica em Camadas, Camadas não implica em MVC.

sim, camadas não são MVC, mas em MVC nós sempre vamos encontrar camadas nem que sejam duas como Java Swing…

Agora com MVC estamos falando de layer’s inicialmente separamos em três camadas se falarmos da arquitetura/padrão MVC e para por ai 3layer

eu só usei como exemplo uma vez que estávamos falando camadas (tier e layer)

baudamix:

sim, camadas não são MVC, mas em MVC nós sempre vamos encontrar camadas nem que sejam duas como Java Swing…

Não. Eu posso não ter qualquer divisão em Camadas e ter MVC. Muita gente cria aplicações em Swing assim, aliás, com os XxxModel da vida que fazem consultas ao banco, executam regras de negócio e escrevem log ao mesmo tempo. VOcê ainda tem um Model só que ele não está numa Camada de Negócios como se esperaria.

Calçado,

então segundo as conversas que se seguiram, a idéia de camadas que falei anteriormente está no caminho correto ?!

Sim, exceto que o XStream serve para muito mais que persistência.

É? Eu dúvido você provar isso.
Mais ainda: provando eu te mando por correio uma perna e um braço.

realmente esse exemplo do fnandos não ficou muito legal… mas voltando àquela definição de antes: um componente não é uma camada! uma camada, eventualmente pode ser formada por apenas um componente, ou seja, não dá pra dizer que o DAO é uma camada, hibernate é outra e etc. E nesse seu exemplo é muito provável que o DAO e o Hibernate trabalhem juntos na mesma camada.

E acho válida uma consulta a esse link da wikipedia sobre mvc para esclarecer os conceitos: http://en.wikipedia.org/wiki/Model-view-controller#Java

Estes dias tive a felicidade (!) de participar de um flame - que jurava que, o professor dele (ph.d., arquiteto, etc.) dizia que camadas == MVC e que, como MVC é dividida em tres letras, existiam em todos sistemas 3 camadas.

que fique claro, mvc é um padrão arquitetural que demonstra como as partes da sua aplicação se comunicam. As camadas são a divisão do seu projeto, podendo variar de 3 … (normalmente 4) para N.

Seriam: apresentação, controle, aplicação, persistência, etc.

MVC realmente não implica em camadas, mas no mínimo em uma separação em 3 partes com resposnsabildiades distinas. Essas 3 partes podem estar na mesma camada, mas via de regra quase todo framework ou arquitetura coloca V e C na camada de apresentação e M na camada de negócio ou persistência.

horacio_barros:

No seu caso, o MODEL sera seu banco de dados, HIBERNATE é
o seu Controller …

fbarreto:

Ola bom dia pessoal,estou trabalhando em um projeto que utiliza MVC,DAO,JSF,Hibernate minha duvida é a seguinte,Quantas camadas possui meu Sistema?
MVC-3
DAO é uma camada?
O contexto de Persistencia do hibernate é uma camada?

Camada pode significar 3 coisas :
agrupamento de classes que executam uma funcionaldiade: camada de persistencia (tradução de layer)
sistema distribuido: Sistemas três camadas : cliente-midleware-banco (tradução ruim de tier)
agrupamento de classes que executam uma operação diferente do ponto de vista do software : camada de apresentação (também tradução de layer)

Clarifique-se que :
camada = conjunto de classes que executam uma funcionaldiade
andar = agrupamento de classes que executam uma operação diferente do ponto de vista do software
plataforma = pliha de tecnologias e/ou parte dela que ligam o software ao hardware.
nodo = unidade de execução do sistema distribuido.

JSF = padrão tecnologico. Podemos considerar uma plataforma se quisermos.
MVC = padrão de projeto usualmente utilizado na camada de apresentação.( integra o JSF e o Swing, pro exemplo)
DAO = padrão de projeto utilizado na camada de persistencia.
Domain Store = outro padrão de projeto utilizado na camada de persistencia.
Hibernate = implementação particular do padrão Domain Store

DAO não é uma camada, faz parte de um camada. Outros objetos que podem fazer parde dessa camada são os QueryObjects.
O contexto de persistencia é um conceito. Não é uma camada.
MVC não é uma camada nem 3 camadas. Implementações dele formam uma só camada. Existem normalmente vários objetos nesta camada( vide Swing)

Conceitos de Arquitetura
MVC

pcalcado:

Não. Eu posso não ter qualquer divisão em Camadas e ter MVC…
[]

Agora com MVC estamos falando de layer’s inicialmente separamos em três camadas se falarmos da arquitetura/padrão MVC e para por ai 3layer.

Para framework MVC web eu vejo assim 3layer, posso estar errado e aprender um pouco mais com uma explicação…

obrigado…

Aqui está um excelente artigo sobre camadas e MVC,
http://www.fragmental.com.br/wiki/index.php?title=MVC_e_Camadas

Leitura recomendada!

recomendo essa tbm

Lembrando que nenhuma tecnologia em Java implementa MVC “as-is”. Web geralmente é baseado em Front Controller. Aplicações JSF geralmente são somente Application Façades. Aplicações Swing tem um MVC numa implementação própria. MVC é muito mal compreendido.

Confundir MVC com camadas é muito comum. Creio que a confusão vem do padrão “boundary-control-entity” que era muito citado nos primórdios da literatura UP (Jacobson, Booch, Rumbaught e cia ltda). Um não tem nada a ver com o outro.

Geralmente as aplicações atuais se separam em camadas view, application, domain model e infrastructure. A view poderia ser seu JSP, a application poderia ser seu managed bean JSF, Action ou um outro Service qualquer (é comum ter um Application Façade aqui), o domain model (não confunda com o Model do MVC) seria suas entidades/repositórios/services/value objects de negócio. A infra garante que a sua arquitetura é viável nesse nível de abstração (mailing, network, filesystem, mensageria, database e toda a porrada de frameworks que garantem o binding de tudo isso estaria na infra).

Perfeito!!

Perfeito!!

Dale DDD! :twisted:

E se um servidor fornecer apenas XML e delegar a responsabilidade de apresentação para os seus clientes, pode-se dizer que ele está completamente isento da camada de apresentação? Pra mim parece que sim, mas e a interface que disponibiliza os XMLs, a que envia quando ele já está pronto, faz parte de qual camada? Poderia ser um serviço na camada de negócio (parece não soar bem)?

Posso estar enganado, mas parece-me que muita gente confunde o modelo de domínio de uma aplicação com o componente Model do MVC.

baudamix:

Concordo em partes, acho esse exemplo valido só para provar que pode se fazer uma aplicação swing mal feita(o famoso código fortran), uma calculador sim, mas um sistema de verdade? duvido … mas como vc disse “…Muita gente cria…” posso estar errado eu não faria assim e não aconselho ninguém a fazer.
[…]
Agora com MVC estamos falando de layer’s inicialmente separamos em três camadas se falarmos da arquitetura/padrão MVC e para por ai 3layer.
Para framework MVC web eu vejo assim 3layer, posso estar errado e aprender um pouco mais com uma explicação…

obrigado…

Não, o que o exemplo prova é que é possível ter MVC sem Camadas, além de ser possível ter Camadas sem MVC. Não confunda o que você acha correto -o que é correto, na verdade, depende da situação- com o que é o padrão.

Sim, para deixar esse conceito mais simples, MVC é um padrão que fica mais na camada de apresentação e geralmente o model é um Application Façade.

Na MundoJava #23 no artigo “Design Patterns para um Mundo Real parte 3” falei sobre esse assunto e coloquei uns desenhinhos para explicar…

2008/5/28/2af37aa64066abaf35d2496d5eb6749e_8888.gif700×331 5.81 KB

Acho que seu diagrama dos circulos tem um problema, yoshi, a infraestrutura nao eh soh contida pelo dominio. A Camada de Apresentação ambém usa infra-estrutura.

Uma boa forma de estrutuar isso são os domínios do Page-Jones.

Naked Objects seriam um exemplo do uso de MVC sem camadas, certo?

Esse meu “diagrama” é uma adaptação disso aqui:

http://martinfowler.com/eaaCatalog/serviceLayer.html

De fato aquele diagrama do Evans é melhor para explicar essas dependências apesar de ser meio macarrônico. Esse “alvo” dá a entender que só o Domain Model depende de infra, mas essa figura não explica bem as dependências e sim um relacionamento que é muito comum entre as camadas não interessando as dependências, mas delineando as responsabilidades. Geralmente até a minha camada de application depende de infra.

Essa sobreposição entre Application Layer [Evans] e Service Layer [Fowler] é uma coisinha que também gera muita confusão.

Não exatamente, pelo qe lembro. Naked objects obedece ao adrão view-é-atualizada-pelo-observer mas ele não tem um controller, que recebe a ação é o objeto (model) em si.

Para ter MVC sem camadas é simples, na verdade a grande maioria dos sistemas não usa Camadas e possui um controller.

rodrigoy:

Esse meu “diagrama” é uma adaptação disso aqui:

http://martinfowler.com/eaaCatalog/serviceLayer.html

Creio que não. O seu diagrama mostra “Infra-estrutura”, isso é muito mais amplo do que “data source layer”.

Olhadando agora a wikipedia sobre naked objects, http://en.wikipedia.org/wiki/Naked_objects ,
encontrei isso:

Por isso a minha dúvida, pois o objeto de modelo também funciona como um controle em si. :roll:

Se o modelo de objetos funciona como controller E model não é MVC

Mas naked objets em si é sustentado por um framework. Eu não consigo ter certeza mas acho que o framework Não é MVC, em compensação nada e impede de usar a idéia com um MVC por trás, o ponto é que isso não seria útil nesta abordagem.

pcalcado:

Creio que não. O seu diagrama mostra “Infra-estrutura”, isso é muito mais amplo do que “data source layer”.

Achei muito bom o seu post. O único ponto que meu diagrama mostra dependências é esse conceito que vc explicou. Não é saudável que meus Domain Objects dependam dos meus Application Façades e etc…

No artigo, quando citei infra pensei em tudo quanto é framework e libs que usamos para suportar principalmente o Domain Model (Hibernate, XStream, JavaMail, JMS, JCR e zilhares de outros). As camadas de view e de aplicação geralmente dependem de uma outra infra própria (JSF, Seam, WebWork, Struts!, achoqueestanahoradecomeçarausarrails e etc…).

Seu diagrama mostra Camadas opacas, Rodrigo, não?

Shoes, como assim? Opacas?

A Camada N fala com qualquer uma ou apenas com N-1?

Nada impede a View de acessar diretamente o Domain Model. N fala com qualquer camada abaixo.

Então, sendo “inra-estrutura” mais que data layer porque colocar ela como Camadas empilhadas?

Acho que você está tratando as Camadas d artigo como as Camadas normais (de ‘3 Camadas’). Elas são diferentes. As Camadas deste artigo em específico são sobre reusabilidae, não sobre separação de responsabilidades.

Basicamente, se você mudar o nome de ‘infra-estrutura’ para ‘acesso a dados’ eu fico satisfeito. Infra é muito mais que isso.

Mas para isolar um domain model as vezes acabamos “meio” que misturando camadas, ou ao menos parece que estamos misturando, como por exemplo um Repositorio ser implementado por uma DAO (que pertence a camada de persistência). Neste caso a camada de baixo (persistência) está dependendo da camada de cima (domain). O que muitos consideram um estupro ao conceito de camadas.

Lembro que li no artigo da MundoJava 17 escrito pelo Shoes que neste caso os conceito de camadas não é ferido quando utilizamos DIP, pois assim dependeriamos apenas de abstrações. Porém vejo muitas discussões sobre isso, principalmente quando se fala de um repositório ser implementado por um DAO.

No final das contas, realmente está havendo ou não a dependência da camada de baixo por uma camada superior? Ou é apenas rigidez conceitual de muitos?

Se você possui uma linguagem que te obriga a declarar interfaces e tipos como Java, este tipo de arquitetura é uma quebra de conceitos sim. Se esta quebra é relevante ou não para você depende, você sempre pode ter um Repositorio implementado por uma classe que chama um DAO, mas o que esta fazendo neste caso é criar uma classe a mais apenas para suprir um caprcho arquitetônico, creio.

rodrigoy:

… infra (esse miolo do diagrama) é tudo quanto é framework e libs que usamos para suportar principalmente o Domain Model (Hibernate, XStream, JavaMail, JMS, JCR e zilhares de outros).

Shoes, vc concorda com isso acima? JavaMail e JMS são “data acess”?

A parte de infra que é importante, que precisamos separar e possivelmente isolar, são esses “serviços” de suporte ao Domain Model. A infra de suporte das outras camadas sempre são acopladas com elas e dificilmente há isolamento.

rodrigoy:

rodrigoy:

… infra (esse miolo do diagrama) é tudo quanto é framework e libs que usamos para suportar principalmente o Domain Model (Hibernate, XStream, JavaMail, JMS, JCR e zilhares de outros).

Shoes, vc concorda com isso acima? JavaMail e JMS são “data acess”?
[…]
A parte de infra que é importante, que precisamos separar e possivelmente isolar, são esses “serviços” de suporte ao Domain Model. A infra de suporte das outras camadas sempre são acopladas com elas e dificilmente há isolamento.

Uma framework como XStream vai depender da finalidade. É para persistir? É para gerar webservice REST?

O que -acredito- você não entendeu é que Camada != Camada. A Camada Fundamental -Pae-Jones- vai conter este tipo de framework/biblioteca. A Camada -Apresentação/Neócios…- vai separar seu uso. A Camada’ de Apresentação pode usar recursos da Camada’’ Fundamental ou de Infra-Estrutura.

Seu diagrama não fala de Camada de Domínios -que é o assunto do meu blog-, fala de Camadas como padrão arquitetural. Quando falei para ovcê ler o blo não era sobre as Camadas em si mas em termos de organização do código em diversos domínios.

Classes dos domínios (Camadas Page-Jones) inferiores podem ser acessados em qualquer lugar. Acho que a confusão toda se deu porque tentamos relacionar seu gráfico com os domínios. Seu gráfico possui um “Infra-estrutura” mas isso não significa apenas Camadas como a de Persistência e sim coisas que sustentam a aplicação em si, por isso sueri que mudasse.

Não. Apresentação não significa GUI. Apresentação significa "o que o sistema mostra ‘para fora’ ". As palavras não sua muito boas, mas a ideia é que a camada de apresentação gerencia a interação da aplicação com o seu usuário. Mas usuário não é necesáriamente usuário humano. Então esse XML gerado ai é a apresentação do sistema. É o que ele mostrar ‘para fora’.

Um Webservice , por exemplo, tem uma apresentação que é o protocolo SOAP.

Posso estar enganado, mas parece-me que muita gente confunde o modelo de domínio de uma aplicação com o componente Model do MVC.

Sim. É verdade. Também é confundido com outros padrões como Façade ou Adapter.
O Model do MVC é um objeto da mesma camada, cuja interface e funcionamento obdecem os padrões do MVC e da camada em particular. O exemplo mais claro disto é o TableModel do Swing. O contrato do Model é com a View e o Controler, não é com o dominio. O model é na realidade uma forma de Mediador que traduz informação entre a camada MVC e a camada “abaixo”.
Essa camada tem um ponto de entrada. Agora sim, um façade ou um serviço ou algo assim. O modelo usa o façade/serviço/etc…, mas ele em si proprio não é um façade/servicço/etc.

No Struts, por exemplo, o model seria o Action. Muita gente defende que o Action é o controlador, mas na realidade o controlador é o próprio struts na figura do seu servlet principal. É o action que é chamado em ultima instancia é ai que a interação com o dominio acontece. Logo, ele é o Model do struts ( sendo o controlador o proprio struts e a view páginas JSP ou templates em outras tencologias).

Realmente a confusão do conceito do component Model do MVC e o cnceito de Modelo em geral se confundem. Especialmente com o modelo de dominio.

Como eu disse eu não faria e não recomendo isso…[obs.:minha opinião pessoal]

Se vc trabalha e recomenda fazer MVC assim, tudo bem “dependendo da situação”… se é correto ou não eai isso “dependendo da situação” entendo, só gostaria de um exemplo real para aprender um pouco mais…
::sua posição tem sido mto didática para minha e pouco real(dia-a-dia)…

O q eu acho correto pode e deve estar errado e quero aprender e refinar meus conhecimento…
obrigado por insistir pcalcado…

até

Não. Apresentação não significa GUI. Apresentação significa "o que o sistema mostra ‘para fora’ ". As palavras não sua muito boas, mas a ideia é que a camada de apresentação gerencia a interação da aplicação com o seu usuário. Mas usuário não é necesáriamente usuário humano. Então esse XML gerado ai é a apresentação do sistema. É o que ele mostrar ‘para fora’.

Um Webservice , por exemplo, tem uma apresentação que é o protocolo SOAP.

Interessante. Eu já havia lido em algum lugar, talvez no teu blog :D,mas não havia assimilado.

Obrigado!

A questão é simples, creio. A pergunta é: dá para ter MVC sem Camadas e vice-versa? A resposta é: sim, um não depende do outro.

Se desenvolver sem Camadas é ruim, se toda aplicação do mundo deveria ser MVC ou qualquer outra pergunta parecida é outro assunto.

Se você não usar MVC na sua aplicação web, digamos que resolver fazer tudo com servlets que cospem HTML por algum motivo, por exemplo porque você não pode ter páginas JSP, você não precisa deixar de usar Camadas.

Se você usa MVC mas sua aplicação é apenas um front-end burro para um banco de dados ou outro sistema e o banco de dados é seu modelo você não tem Camadas mas tem MVC. Aliás, o que mais tem por aí é sistema onde as regras de negócio estão nas Actions. Estes sistemas não têm Camadas bem definidas mas ainda assim podem ser MVC.

pcalcado , obrigado…

Se está delegando a apresentação é porque a idéia é ficar independente dela, ou então algo está errado.

Muito boa sua explicação Sérgio… só tenho uma dúvida: é sempre necessário ter um modelo na camada de apresentação do MVC que, então , se encarregará de acessar o domain model/ service layer?? Em alguns casos, esse model vai simplesmente delegar p/ o service layer/façade e, neste caso, não seria melhor o controlador trabalhar diretamente com a interface p/ o service layer? Se sim, neste caso, o próprio service layer faria o papel do modelo MVC, estando assim situado em outra camada.

Se está delegando a apresentação é porque a idéia é ficar independente dela, ou então algo está errado.

Sim. Quando eu fiz a pergunta já fiz imaginando uma situação que estou “vivenciando” hoje. Quero que o servidor apenas disponibilize o conteúdo em forma de XML. A parte de apresentação pro usuário humano gostaria que ficasse por conta de outras aplicações, seja J2ME, Swing ou outro servidor que somente “monte” as páginas Web pra acesso. Outro motivo foi a possível troca de dados com outras aplicações semelhantes posteriormente.

Falou!