[quote=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?
[/quote]
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)
[quote=pcalcado]
Não. Eu posso não ter qualquer divisão em Camadas e ter MVC…
[][/quote]
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.
[quote]
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.[/quote]
Para framework MVC web eu vejo assim 3layer, posso estar errado e aprender um pouco mais com uma explicação…
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).
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.
[quote=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…[/quote]
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.
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.
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.
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.
[quote=pcalcado]
Creio que não. O seu diagrama mostra “Infra-estrutura”, isso é muito mais amplo do que “data source layer”.[/quote]
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…).
