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.
[quote=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).
[/quote]
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.
[quote=rodrigoy][quote=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).
[/quote]
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.
[/quote]
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.
[quote]
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]
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.
[/quote]
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.[/quote]
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!