Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
eu vi que esse post gerou muita discursão... Na epoca estavam discutindo que a MVC implementa 1 camada (e não 3....). Eu entendi o conceito (camada de apresentação=MVC) mas como os padrões mudam e hoje existe camada pra tudo queria saber como isso está hoje??... eu li muito sobre o assunto e minha opinião é mais o menos o que essa figura diz...
PS: coloquei WebServices e Sistemas legados dentro de Negócios a titulo de acesso, ou seja, a camada de negócios apenas acessa esses sistemas (não implementa).
eu queria saber qual posição hoje sobre o assunto ??? entendi certo ou estou longe de enteder ??? _________________
Mais importante que o CONHECIMENTO é o que se pode fazer com ele!
Na verdade não houve consenso naquela discussão e não houve, principalmente, porque há diferentes conceitos de model entre quem participou. Eu ainda continuo achando que MVC é composto de 3 camadas e isso foi mostrado num dos posts do miojo com a descrição de cada camada nesse pattern. Uma afirmação simples mas que, a meu ver, demonstra que MVC é composto de 3 camadas e não apenas relacionado a view é: "se esse treco fosse apenas view, uma mudança nas view imporia mudanças no model e no controller o que não é verdade, claro."
No mais, deixa que depois o Jean vem aqui e cospe algumas afirmações tambem.
valeuz...
_________________
Marcos Silva Pereira http://marcospereira.wordpress.com Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (Fowler)
Já adianto: não li a thread referida, portanto, não me digam "você não leu o post do miojo?", ok?
Como tenho preguiça de ler toda a thread antiga (6 páginas!), vou por lenha na fogueira aqui, pra ver no que é que dá. :)
- Camadas == Layers O padrão que descreve a separação do sistema em camadas é o Layers, publicado em [Busch98] (referências no final). Este padrão mostra uma divisão do sistema em camadas, onde idealmente uma camada conhece e acessa apenas a camada imediatamente inferior, ou no máximo as camadas adjacentes.
- MVC = Model-View-Controller Padrão usado na implementação do toolkit gráfico do Smalltalk. Uma descrição pode ser encontrada aqui.
Eu acredito que a confusão existe por causa da correspondência numérica que muitas vezes ocorre entre os padrões: MVC e Apresentação/Negócio/Persistência. Então, muitos acham que é a mesma coisa, o que não é verdade.
O padrão MVC, como implementado no Swing, funciona da seguinte maneira: O componente recebe o input do usuário, interpertando-as; este componente envia ao modelo as alterações causadas pelo input; se o modelo for alterado, este envia uma notificação às views (que também são componentes), que por sua vez solicitam ao modelo os novos dados, para que possam se atualizar. Aqui pode se notar um triângulo, Controlador -> Modelo -> Visualização -> Controlador. Assim, o conceito de separação em camadas não é válido, pois a vizualização acessa diretamente o modelo (isto é, não existe a separação estrita em camadas).
Eu, pessoalmente, não acredito que a implementação para web siga de maneira estrita o padrão MVC, mas vamos lá. Usarei o Struts como exemplo, mas eu creio que todos os ditos frameworks MVC têm as mesmas características básicas.
Primeiro, o Struts é usado em que camada? Apresentação, creio. Mas cada um usa o Struts de sua própria maneira, então vamos ver alguns casos.
Em muitos sistemas, a lógica de negócio fica nas próprias classes Action, usando, então, o controlador (as classes Action são apenas extensões da servlet controladora) como se fosse a camada de negócio. Estas classes acessam DAOs (ou diretamente o banco, mas então não haveria a camada de persistência), buscando os dados, efetuando qualquer processamento necessário e armazenando estes dados: ou de volta ao banco, em objetos ActionForm, ou apenas como atributos de sessão. As páginas JSP, por sua vez, buscam os dados ou de DAOs, ou de ActionForms para sua renderização. Percebam que, caso o acesso seja direto aos DAOs, existe novamente um triângulo (Controlador->DAO<->JSP->Servlet), o que quebra a separação estrita em camadas (apresentação acessando diretamente a persistência). E caso os dados sejam primeiro armazenados em um ActionForm ou em sessão, existe a separação da camada de persistência, mas a separação entre a camada de apresentação e de negócio fica um pouco nebulosa. Então, a separação entre Model, View e Controller não seria correspondente direto das camadas de Persistência, Apresentação e Negócio, respectivamente, no máximo o MVC englobaria as camadas de apresentação e negócio, separadas da persistência.
Tomando uma arquitetura mais elaborada, criamos uma Façade (SessionFaçade com EJBs, ou uma ServiceFaçade com ApplicationServices), separando a camada de negócio da camada de apresentação. Neste caso, as Actions apenas serviriam para transformar as requisições em chamadas de negócio (a função original do Controller). Toda a dependência com o Struts, consequentemente o MVC, ficaria isolado na camada de apresentação, portanto, este não representaria as camadas.
Portanto, é até possível falar de MVC como se fossem camadas (de maneira bem livre), mas deve-se ter em mente que se um dos dois padrões estiver seguindo perfeitamente seu conceito original, o outro será violado pelo menos em parte, devido à própria natureza dos padrões (triângulo vs. barras paralelas).
Idealmente, acredito que o MVC faz parte da camada de apresentação (como era no conceito original), e não como divisor de camadas (o que deturpa o conceito de MVC e confunde a separação correta em camadas).
[Busch98] BUSCHMANN, Frank, MEUNIER, Regine, ROHNERT, Hans, SOMMERLAD, Peter, STAL, Michael. Pattern-Oriented Softwar Architecture: A System of Patterns. 4 ed. Chichester: John Wiley & sons Ltd., 1998. ISBN 0-471-95869-7
[CorePatterns] ALUR, Deepak, CRUPi, John, MALKS, Dan. Core J2EE Design Patterns: Best practices and Design Strategies. 2 ed. Upper Saddle River, NJ: Prentice Hall PTR, 2003. ISBN 0-13-142246-4
O Swing, na verdade não implementa o MVC exatamento dito, ele foi construído em cima do Event Delegation (bonito isso né???) então, ele funciona com modelos, mas a view e o controle são "comprimidos" em uma única camada chamada UserInterface(UI)
Segundo, como o Ronald falou são duas coisas diferentes. MVC e 3 Camadas. Um bom questionamento é que eu poderia estar usando 4 ou 5 camadas .
Além disso, nada impede que se possa ter um MVC dentro de um outro MVC ( ). Como por exemplo o Swing, não é MVC, mas se fosse, ele seria só a view de um outro MVC maior GLOBAL
na época desse post achei muito estranho e resolvi parar de acompanhá-lo para não confundir minhas idéias!
_________________
Carlos E. A. Barretto Bacharel em Ciência da Computação Sun Certified Java Programmer 1.4 Sun Certified Web Components Developer 1.4 JavaFree.org
Ricardo, A minha concepção ainda é semelhante (MVC é parte da camada de apresentação), embora o modelo, como dito na discussão, pode ter conceitos distintos. Acho que o seu diagrama simplifica um pouco o paradigma de arquitetura, e assim sendo, deveria distribuir melhor os componentes de negócio.
Um exemplo é que um web service não concentra suas atividades no modelo de negócio. É mais uma interface de comunicação com outros sistemas e portanto, faria parte de uma camada chamada "integração". O mesmo se daria com códigos como RMI, ou CORBA por exemplo. DAO's fariam parte da camada de persistência. Session Beans fariam parte da camada de negócio, assim como os DTO's (que fariam parte do Model do MVC). Porém, Entity Beans fazem parte da camada de persistência. Assim como outras alternativas como LDAP.
Certo?
Arquitetura de sistemas muitas vezes é semelhante a um jogo de xadrez: possui certo nível de subjetividade e muitas vezes, um mesmo problema pode ter diversas soluções com arquiteturas bem distintas e igualmente eficazes.
_________________ Jean R. Rodrigues Oracle/J2EE Premium Support Engineer Instrutor Certificado Sun e Oracle (Especialista América Latina) Certified ScrumMaster
Eu acredito que a confusão existe por causa da correspondência numérica que muitas vezes ocorre entre os padrões: MVC e Apresentação/Negócio/Persistência. Então, muitos acham que é a mesma coisa, o que não é verdade.
Exato. Essa é a mesma concepção que tenho.
ronaldtm:
Eu, pessoalmente, não acredito que a implementação para web siga de maneira estrita o padrão MVC, mas vamos lá. Usarei o Struts como exemplo, mas eu creio que todos os ditos frameworks MVC têm as mesmas características básicas.
Primeiro, o Struts é usado em que camada? Apresentação, creio. Mas cada um usa o Struts de sua própria maneira, então vamos ver alguns casos.
Portanto, é até possível falar de MVC como se fossem camadas (de maneira bem livre), mas deve-se ter em mente que se um dos dois padrões estiver seguindo perfeitamente seu conceito original, o outro será violado pelo menos em parte, devido à própria natureza dos padrões (triângulo vs. barras paralelas).
MVC originalmente sempre pretendeu resolver problemas inerentes a camada de apresentação. Portanto, acho ilógico mesclar mais camadas se o problema que deve ser isolado é o da apresentação.
ronaldtm:
Idealmente, acredito que o MVC faz parte da camada de apresentação (como era no conceito original), e não como divisor de camadas (o que deturpa o conceito de MVC e confunde a separação correta em camadas).
[Busch98] BUSCHMANN, Frank, MEUNIER, Regine, ROHNERT, Hans, SOMMERLAD, Peter, STAL, Michael. Pattern-Oriented Softwar Architecture: A System of Patterns. 4 ed. Chichester: John Wiley & sons Ltd., 1998. ISBN 0-471-95869-7
[CorePatterns] ALUR, Deepak, CRUPi, John, MALKS, Dan. Core J2EE Design Patterns: Best practices and Design Strategies. 2 ed. Upper Saddle River, NJ: Prentice Hall PTR, 2003. ISBN 0-13-142246-4
Perfeito. :!:
_________________ Jean R. Rodrigues Oracle/J2EE Premium Support Engineer Instrutor Certificado Sun e Oracle (Especialista América Latina) Certified ScrumMaster
Uma afirmação simples mas que, a meu ver, demonstra que MVC é composto de 3 camadas e não apenas relacionado a view é: "se esse treco fosse apenas view, uma mudança nas view imporia mudanças no model e no controller o que não é verdade, claro."
jrodrigues:
...o modelo, como dito na discussão, pode ter conceitos distintos.
vfpamp:
Além disso, nada impede que se possa ter um MVC dentro de um outro MVC. Como por exemplo o Swing, não é MVC, mas se fosse, ele seria só a view de um outro MVC maior GLOBAL
Eu não mudei de opnião e concordo com o ponto de vista citado pelo Jack mas entendi melhor o ponto de vista do Jean, e como o Vitor citou, como não tem nada que impede de vc aplicar o mvc em um nível maior ou menor, então depende da abordagem.
Na época o Jean postou no JavaRanch tb, seguem os links.
PS: Qual é a lei que diz que não posso ter um MVC na camada de Controle? ou na Model???
Bem... Model/View/Controller? Em que camada existe uma visualização se não na de apresentação? (views de bancos de dados não contam )
De maneira simples, padrões são soluções bem testadas para problemas em contextos repetidos. O MVC foi bem testado para coordenação de componentes visuais. Você pode tentar usá-lo em outros contextos, mas fique avisado que ou isso não foi bem testado, ou foi testado e não funcionou muito bem...
Aliás, a idéia de MVC para web é relativamente nova, apenas uma adaptação do MVC original do Smalltalk, já que o paradigma web (http) não suporta notificações do mesmo modo que componentes GUI.
E o que são a camada de Controle e 'a Model'? É claro as camadas devem ser definidas visando coerência e dependem do tipo de sistema, isto é, cada um cria as camadas que achar necessário, mas pelo menos hoje em dia, em sistemas corporativos J2EE, as camadas mais comuns são Apresentação, Negócio, Integração e Persistência (sendo que as últimas muitas vezes são combinadas em uma só). "Controle" se encaixaria melhor em um contexto de subsistemas ou componentes, pois envolve coordenação e notificação, conceitos que, ao meu ver, não mesclam muito bem com divisão em camadas. "Model" poderia ter como correspondente a camada de persistência, já que no MVC o Model é quem guarda as informações de estado. Porém, "persistência" tem um significado definido, mas o que é o "model", num contexto de uma aplicação corporativa (presumo que este seja o contexto, já que este é o mais apropriado para separação em camadas)?
PS: Qual é a lei que diz que não posso ter um MVC na camada de Controle? ou na Model???
Bem... Model/View/Controller? Em que camada existe uma visualização se não na de apresentação? (views de bancos de dados não contam )
View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.
Eu defendo a idéia de que a View que o pattern fala não é uma UI com usuário, é uma Interface com alguma coisa. Por exemplo um WebService pode ser um View. Assim se eu separar o meu modelo de dados para permitir uma independência de metodologia de persistência, eu posso criar uma view para que outras aplicações acessem a minha API, que irá retornar os dados do jeito que eles desejarem
O Swing, na verdade não implementa o MVC exatamento dito, ele foi construído em cima do Event Delegation (bonito isso né???) então, ele funciona com modelos, mas a view e o controle são "comprimidos" em uma única camada chamada UserInterface(UI)
Corretíssimo. Porém, o Swing herda muito do MVC original. A separação entre view e controller é feita de modo implícito, já que é possível se estender o controller (por meio de tratamento de eventos) e se ter mais de uma view para um model. Esta flexibilidade demonstra um desacoplamento razoável entre os dois, apesar de serem implementados na mesma classe. Então, acho justo afirmar que o Swing segue a filosofia do MVC na implementação de seus componentes.
vfpamp:
Um bom questionamento é que eu poderia estar usando 4 ou 5 camadas .
Mas a separação mais usual atualmente, no contexto de uma aplicação web, é apresentação, negócio e persistência.
View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.
Renders, presented, presentation... apresentação?
vfpamp:
Por exemplo um WebService pode ser um View.
Um webservice por definição é stateless. Os frameworks MVC usados para web servem para guardar a lógica de navegação entre as páginas de uma aplicação. Navegação pressupõe estado. Apesar de usar o protocolo http para comunicação, webservices são acessados diretamente pela aplicação cliente, sem a necessidade de passar por um controlador responsável pela decisão do fluxo, pois não há fluxo. Você até pode configurar um webservice no Struts, mas isso é só um workaround, pois um webservice não deveria necessitar de navegação anterior ou posterior à sua execução.
vfpamp:
Assim se eu separar o meu modelo de dados para permitir uma independência de metodologia de persistência,
Isso é só a separação da camada de persistência, não tem nada a ver com MVC.
vfpamp:
eu posso criar uma view para que outras aplicações acessem a minha API, que irá retornar os dados do jeito que eles desejarem
O que é essa view? As aplicações irão ler e preencher formulários, pra depois clicar em botões para chamar seu webservice?
O que você descreve é uma API, uma interface de programação. Parâmetros de entrada, dados de saída. A única diferença é que o protocolo de comunicação entre as aplicações não é RMI, ou chamadas locais de métodos, mas XML sobre HTTP.
E quero que a minha aplicação faça a persistência tanto em banco de dados quanto em um Prevayler da vida, tudo configurado por um arquivo XML Futuramente, vou querer usar duas ou três persistências simultâneas (Segurança de informação )
Sendo assim, eu monto uma equipe que cuida somente da camada de persistência, como gravar, restaurar, transformar em objetos e devolver para a lógica.
Então defino métodos de entrada e saída desse framework que será montado, por exemplo: - insert(Dado qualquerDado); - update(Dado qualquerDado); - delete(Dado qualquerDado); - getDado(OQL oql); - addClassListener(ClassListener listen) ....
Então a classe que mantém esses métodos será a view, pois ele é a fronteira do meu framework. Teremos outras classes cuidando da persistência, da lógica de buca e atualização que poderão ser dividadas entre Controle e Modelo propriamente dito
View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.
Renders, presented, presentation... apresentação?
Não posso apresentar somente um conjunto de métodos ??
Então a classe que mantém esses métodos será a view, pois ele é a fronteira do meu framework. Teremos outras classes cuidando da persistência, da lógica de buca e atualização que poderão ser dividadas
Mas daí seria apenas uma separação em subcamadas. A definição da interface é só um passo para esta separação: "interfaces bem definidas".
A lógica de busca e atualização em um controlador eu até entendo, mas também seria uma separação em subcamadas. E o modelo, onde entra, já que a persistência já está sendo cuidada por outras classes? Seria o outro lado da fronteira (o que chama)?
Além do mais, o exemplo que você deu contém múltiplos modelos, e não "views" ou "controladores". O modelo deveria ser único, para manter a consistência dos dados, não?
Pegando o método getDado(OQL oql); por exemplo. A OQL (Object Query Language) é uma SQL da vida, só que para objetos. Quem vai processar a OQL para saber que tipo de dado o desenvolvedor necessita?
O Controller , ele vai verificar qual é o modelo de persistência existente e fará a sua atuação. Por exemplo, se a persistência for o Prevayler ele varre os objetos e índices para encontrar os dados, se for um banco relacional, ele transforma isso em SQL e lança para o banco processar.
A View seria a classe de entrada dessas chamadas, irá dispor um conjunto de regras para que os usuários a utilizem, como um formulário HTML .
O Model seria os dados propriamente ditos juntamente com as classes de dados e o banco de dados.
PS: Nunca fiz uma arquitetura assim, estou falando como eu faria uma dessas
Pegando o método getDado(OQL oql); por exemplo. A OQL (Object Query Language) é uma SQL da vida, só que para objetos. Quem vai processar a OQL para saber que tipo de dado o desenvolvedor necessita?
Você vai implementar todo um framework JDO-like? Boa sorte...
vfpamp:
O Controller , ele vai verificar qual é o modelo de persistência existente e fará a sua atuação. Por exemplo, se a persistência for o Prevayler ele varre os objetos e índices para encontrar os dados, se for um banco relacional, ele transforma isso em SQL e lança para o banco processar.
Não seria melhor uma combinação TO/DAO/AbstractFactory? O DAO encapsula a lógica de persistência, recebendo apenas TOs. Assim, não seria preciso trabalhar com OQL (e fazer um parser, um interpretador, um conversor pra SQL) na aplicação, somente no DAO. E para escolher entre as implementações do DAO (para relacional, objeto, xml, etc), use uma fábrica abstrata configuravel. Ou você realmente quer fazer um JDO personalizado? A propósito, para a implementação deste tipo de framework existem padrões específicos (conhecidos, testados e aprovados pelo teste do tempo), você não precisa tentar usar MVC...
vfpamp:
A View seria a classe de entrada dessas chamadas, irá dispor um conjunto de regras para que os usuários a utilizem, como um formulário HTML .
hein? API com front-end HTML? Não entendi.
vfpamp:
O Model seria os dados propriamente ditos juntamente com as classes de dados e o banco de dados.
isso pra mim são: Camadas, TOs e DAOs, talvez BusinessObjects, e não Controllers e Models.
vfpamp:
PS: Nunca fiz uma arquitetura assim, estou falando como eu faria uma dessas
ainda bem. =P
Sério, vocês estão tentando empurrar MVC onde ele simplesmente não se encaixa, tratando outros padrões como se fossem MVC.
Padrões existem como soluções repetidas para um determinado problema, em um determinado contexto. Alguns padrões são aplicados em contextos mais genéricos (Adapter, Proxy, Composite) e podem ser usados em várias ocasiões. Outros são bem específicos para uma determinada função, talvez em um determinado tipo de aplicação (SessionFaçade, DAO, TransactionScript), simplesmente não cabendo em outros contextos.
Muda-se o contexto, procura-se um padrão que se encaixe neste novo contexto, não se usa à força um outro padrão impróprio, só porque este já lhe é familiar.
Sério, vocês estão tentando empurrar MVC onde ele simplesmente não se encaixa, tratando outros padrões como se fossem MVC.
Exato. É isso que acontece hoje em dia. Todo mundo acha que MVC se aplica a qualquer arquitetura. Além do mais, temos diversos tipos de MVC e nem entramos no mérito: - MVC I - MVC II - Pull-MVC ...
MVC NÃO é a arquitetura que "integra" ... caso comtrário vamos ter objetos de negócio relacionados a apresentação complementamente inchados e sem coesão alguma. Além do mais, isso simplemesmente tornará o acoplamento entre as camadas muito mais forte ... o que simplesmente pode inflexibilizar modificações na arquitetura do sistema. Dificuldade para manutenção e para escalar horizontalmente advém de designs assim. _________________ Jean R. Rodrigues Oracle/J2EE Premium Support Engineer Instrutor Certificado Sun e Oracle (Especialista América Latina) Certified ScrumMaster
Eu não sei se eu estou certo ou errado fazendo isso, mas eu to elevando o conceito de MVC a um nível que vcs não estão vendo . Não to querendo dizer que vou colocar um WebWork para controlar os dados da aplicação
Deixa eu ficar na view que o foi o foco da ultima discussão. No conceito normal do MVC, como é descrito: View - Interface com Usuário, HTML, UI do Swing/SWT/AWT.
No meu conceito: Usuário = Desenvolvedor dos processos do cliente. View - Classe(s) ( facade ) que faz a fronteira do framework com o desenvolvedor "normal" do projeto.
Assim: Model: Qualquer coisa que define qualquer coisa Controler: Qualquer coisa que mexe nas definições de uma coisa. View: Qualquer coisa que represente uma integração com uma outra coisa fora do escopo da coisa ao qual o MVC foi aplicado.
Ae galera... pelo que entendi a coisa fica mais ou menos assim...
está faltando alguma coisa ou é isso mesmo ?
Pode ser assim.
Digo e repito: não há um único jeito correto de se fazer um design. Se houvesse, nós projetistas estaríamos desempregados...
correto ronald... só estou querendo ter uma ideia de um sistema "genérico"...
com certeza nunca iremos encontrar um projeto padrão que se encaixe em todos os nossos problemas mas ter a ideia de um correto eu acho que já facilita a adaptação deste para outros... sendo assim, o resultado de cada projeto pode servir de analise para execução de outros, e outros e assim por diante !!! _________________
Mais importante que o CONHECIMENTO é o que se pode fazer com ele!
Eu não sei se eu estou certo ou errado fazendo isso, mas eu to elevando o conceito de MVC a um nível que vcs não estão vendo . Não to querendo dizer que vou colocar um WebWork para controlar os dados da aplicação
Elevando não, baixando, já que a camada de persistência é a última
vfpamp:
Deixa eu ficar na view que o foi o foco da ultima discussão. No conceito normal do MVC, como é descrito: View - Interface com Usuário, HTML, UI do Swing/SWT/AWT.
No meu conceito: Usuário = Desenvolvedor dos processos do cliente. View - Classe(s) ( facade ) que faz a fronteira do framework com o desenvolvedor "normal" do projeto.
Assim: Model: Qualquer coisa que define qualquer coisa Controler: Qualquer coisa que mexe nas definições de uma coisa. View: Qualquer coisa que represente uma integração com uma outra coisa fora do escopo da coisa ao qual o MVC foi aplicado.
PS: As vezes eu não sei de onde eu tiro essas coisas
É... =P
É que isso é só mais uma divisão das camadas, entenda-me... Não existe mais o "triângulo" de interações entre os componentes, mas sim a dependência em relação à camada imediatamente inferior, isto é, padrão Layers.
Erhm... será que essa discussão vai descambar para 6 paginas tambem?! Bom, eu creio que no forum do JavaRanch foram dadas otimas respostas que demonstram o carater multi tier do MVC. Dentre elas, as que achei mais interessantes foram as seguintes:
Quote:
Well, you could be getting caught up in semantics here, you are correct that MVC is an architecture pattern that describes an entire app, but it is generally thought of in terms of the different layers. MVC stresses division of labor, with each layer of the architecture fulfilling a specific purpose.
Model layer - generally contains business logic and some interface to persistent data, like a database. View layer - in it's ideal form, contains nothing but presentation logic. The data transmitted to the View layer is in a format such that the View merely renders it. Controller layer - generally contains control logic for the app, it's like a liason between the Model and the View. Again, in it's purest form, it should only accept requests, retreive information from the model based on those requests, format the info in a way that is compatible with the view, and send the data to the appropriate part of the View layer.
Quote:
But it's not incorrect for me to talk about a classic 3-tiered architecture seeing the database as the Model, the middle tier as the Controller, and the GUI as the View. Now, in this case, the View is actually a complex thing which itself contains a separate Controller and View, and uses the lower tiers as a Model.
Quote:
Each of your 3 tiers can be made up of several tiers themselves. So your presentation tier can itself contain a multitier architecture, and so can your model. The controller too can be created as a multitier structure. Consider an application using Struts (MVC, 3 tier) as the frontend, with the model in Struts existing of calls to an application that delegates those calls to a distributed framework which itself consists of an EJB container calling stored procedures on a database. You now have 3 tiers in the presentation tier one of which is also part of the middle tier which has at least 2 but more likely 3 tiers one of which could be seen as also being part of the model tier. These boundaries are probably where you get confused. The entire system consists of at least 6, more likely 7 or 8 tiers.
No fim das contas essas opiniões refletem bem o que eu penso sobre MVC, em especial, a afirmação de que "cada uma de suas 3 camadas pode ser, ela mesma, composta de varias outras camadas".
valeuz...
_________________
Marcos Silva Pereira http://marcospereira.wordpress.com Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (Fowler)
Ah, sim, Vitor, passa um pouco desse treco pra cá!
valeuz...
_________________
Marcos Silva Pereira http://marcospereira.wordpress.com Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (Fowler)
So your presentation tier can itself contain a multitier architecture, and so can your model.
Não está dizendo que posso ter no model um MVC?
Hehe Não, tá dizendo que você pode ter sub camadas no model. Pelo menos, isso é o que eu entendo por multi tier (no babylon, Tier: fila, fileira, renque; alinhamento; ordem. Renque: tier, layer).
E ele só cita o MVC na camada de apresentação:
Quote:
Consider an application using Struts (MVC, 3 tier) as the frontend,
Galera, estou chegando atrasado para a discussão, mas acho que pode ser válido, abaixo um resumo de toda discussão:
Camada de Persistência - Data Access Object(DAO) Camada de Negócios - Businnes Objects(BO) Camada de Modelo - Data Transfer Object(DTO)/Value Object(VO) Camada de Modelo Resumido - Session Façade Camada de Controle - Controller(Actions Forms) Camada de Visualização - View
Notem que o MVC sozinho não seria o melhor padrão a ser adotado, ele foi desenvolvido para ser acoplado a outros padrões...como o DAO, Façade, BO....
A princípio se fossemos listar apenas os itens referentes ao MVC teríamos:
Camada de Modelo - TO + BO + DAO Camada de Controle - Controller(Actions Forms) Camada de Visualização - View
Notem que para viver só de MVC é necessário forçar a barra na camada Modelo...por isto, procurem adotar outros padrões para facilitar na hora do desenvolvimento.
ricardo.landim Offline
Posts: 86
mais ou menos um ano eu começei a estudar java pra valer mesmo... e navegando no forum do JavaFree eu vi esse post
http://www.javafree.com.br/forum/viewtopic.php?t=1099
eu vi que esse post gerou muita discursão...
Na epoca estavam discutindo que a MVC implementa 1 camada (e não 3....). Eu entendi o conceito (camada de apresentação=MVC) mas como os padrões mudam e hoje existe camada pra tudo queria saber como isso está hoje??... eu li muito sobre o assunto e minha opinião é mais o menos o que essa figura diz...
PS: coloquei WebServices e Sistemas legados dentro de Negócios a titulo de acesso, ou seja, a camada de negócios apenas acessa esses sistemas (não implementa).
eu queria saber qual posição hoje sobre o assunto ??? entendi certo ou estou longe de enteder ???
_________________
Mais importante que o CONHECIMENTO é o que se pode fazer com ele!
jack_-_ganzha Offline
Posts: 4133
Na verdade não houve consenso naquela discussão e não houve, principalmente, porque há diferentes conceitos de model entre quem participou. Eu ainda continuo achando que MVC é composto de 3 camadas e isso foi mostrado num dos posts do miojo com a descrição de cada camada nesse pattern. Uma afirmação simples mas que, a meu ver, demonstra que MVC é composto de 3 camadas e não apenas relacionado a view é: "se esse treco fosse apenas view, uma mudança nas view imporia mudanças no model e no controller o que não é verdade, claro."
No mais, deixa que depois o Jean vem aqui e cospe algumas afirmações tambem.
valeuz...
_________________
Marcos Silva Pereira
http://marcospereira.wordpress.com
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (Fowler)
ronaldtm Offline
Posts: 2299
Já adianto: não li a thread referida, portanto, não me digam "você não leu o post do miojo?", ok?
Como tenho preguiça de ler toda a thread antiga (6 páginas!), vou por lenha na fogueira aqui, pra ver no que é que dá. :)
- Camadas == Layers
O padrão que descreve a separação do sistema em camadas é o Layers, publicado em [Busch98] (referências no final). Este padrão mostra uma divisão do sistema em camadas, onde idealmente uma camada conhece e acessa apenas a camada imediatamente inferior, ou no máximo as camadas adjacentes.
- MVC = Model-View-Controller
Padrão usado na implementação do toolkit gráfico do Smalltalk. Uma descrição pode ser encontrada aqui.
Eu acredito que a confusão existe por causa da correspondência numérica que muitas vezes ocorre entre os padrões: MVC e Apresentação/Negócio/Persistência. Então, muitos acham que é a mesma coisa, o que não é verdade.
O padrão MVC, como implementado no Swing, funciona da seguinte maneira:
O componente recebe o input do usuário, interpertando-as; este componente envia ao modelo as alterações causadas pelo input; se o modelo for alterado, este envia uma notificação às views (que também são componentes), que por sua vez solicitam ao modelo os novos dados, para que possam se atualizar. Aqui pode se notar um triângulo, Controlador -> Modelo -> Visualização -> Controlador. Assim, o conceito de separação em camadas não é válido, pois a vizualização acessa diretamente o modelo (isto é, não existe a separação estrita em camadas).
Eu, pessoalmente, não acredito que a implementação para web siga de maneira estrita o padrão MVC, mas vamos lá. Usarei o Struts como exemplo, mas eu creio que todos os ditos frameworks MVC têm as mesmas características básicas.
Primeiro, o Struts é usado em que camada? Apresentação, creio. Mas cada um usa o Struts de sua própria maneira, então vamos ver alguns casos.
Em muitos sistemas, a lógica de negócio fica nas próprias classes Action, usando, então, o controlador (as classes Action são apenas extensões da servlet controladora) como se fosse a camada de negócio. Estas classes acessam DAOs (ou diretamente o banco, mas então não haveria a camada de persistência), buscando os dados, efetuando qualquer processamento necessário e armazenando estes dados: ou de volta ao banco, em objetos ActionForm, ou apenas como atributos de sessão. As páginas JSP, por sua vez, buscam os dados ou de DAOs, ou de ActionForms para sua renderização. Percebam que, caso o acesso seja direto aos DAOs, existe novamente um triângulo (Controlador->DAO<->JSP->Servlet), o que quebra a separação estrita em camadas (apresentação acessando diretamente a persistência). E caso os dados sejam primeiro armazenados em um ActionForm ou em sessão, existe a separação da camada de persistência, mas a separação entre a camada de apresentação e de negócio fica um pouco nebulosa. Então, a separação entre Model, View e Controller não seria correspondente direto das camadas de Persistência, Apresentação e Negócio, respectivamente, no máximo o MVC englobaria as camadas de apresentação e negócio, separadas da persistência.
Tomando uma arquitetura mais elaborada, criamos uma Façade (SessionFaçade com EJBs, ou uma ServiceFaçade com ApplicationServices), separando a camada de negócio da camada de apresentação. Neste caso, as Actions apenas serviriam para transformar as requisições em chamadas de negócio (a função original do Controller). Toda a dependência com o Struts, consequentemente o MVC, ficaria isolado na camada de apresentação, portanto, este não representaria as camadas.
Portanto, é até possível falar de MVC como se fossem camadas (de maneira bem livre), mas deve-se ter em mente que se um dos dois padrões estiver seguindo perfeitamente seu conceito original, o outro será violado pelo menos em parte, devido à própria natureza dos padrões (triângulo vs. barras paralelas).
Idealmente, acredito que o MVC faz parte da camada de apresentação (como era no conceito original), e não como divisor de camadas (o que deturpa o conceito de MVC e confunde a separação correta em camadas).
[Busch98] BUSCHMANN, Frank, MEUNIER, Regine, ROHNERT, Hans, SOMMERLAD, Peter, STAL, Michael. Pattern-Oriented Softwar Architecture: A System of Patterns. 4 ed. Chichester: John Wiley & sons Ltd., 1998. ISBN 0-471-95869-7
[CorePatterns] ALUR, Deepak, CRUPi, John, MALKS, Dan. Core J2EE Design Patterns: Best practices and Design Strategies. 2 ed. Upper Saddle River, NJ: Prentice Hall PTR, 2003. ISBN 0-13-142246-4
vfpamp Offline
Posts: 6009
Primeiro.. Swing não é MVC
Segundo, como o Ronald falou são duas coisas diferentes. MVC e 3 Camadas. Um bom questionamento é que eu poderia estar usando 4 ou 5 camadas
Além disso, nada impede que se possa ter um MVC dentro de um outro MVC (
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
vfpamp Offline
Posts: 6009
PS: Qual é a lei que diz que não posso ter um MVC na camada de Controle? ou na Model???
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
carlosbarretto Offline
Posts: 1107
na época desse post achei muito estranho e resolvi parar de acompanhá-lo para não confundir minhas idéias!
_________________
Carlos E. A. Barretto
Bacharel em Ciência da Computação
Sun Certified Java Programmer 1.4
Sun Certified Web Components Developer 1.4
JavaFree.org
jrodrigues Offline
Posts: 1338
Ricardo,
A minha concepção ainda é semelhante (MVC é parte da camada de apresentação), embora o modelo, como dito na discussão, pode ter conceitos distintos.
Acho que o seu diagrama simplifica um pouco o paradigma de arquitetura, e assim sendo, deveria distribuir melhor os componentes de negócio.
Um exemplo é que um web service não concentra suas atividades no modelo de negócio.
É mais uma interface de comunicação com outros sistemas e portanto, faria parte de uma camada chamada "integração".
O mesmo se daria com códigos como RMI, ou CORBA por exemplo.
DAO's fariam parte da camada de persistência.
Session Beans fariam parte da camada de negócio, assim como os DTO's (que fariam parte do Model do MVC).
Porém, Entity Beans fazem parte da camada de persistência. Assim como outras alternativas como LDAP.
Certo?
Arquitetura de sistemas muitas vezes é semelhante a um jogo de xadrez: possui certo nível de subjetividade e muitas vezes, um mesmo problema pode ter diversas soluções com arquiteturas bem distintas e igualmente eficazes.
_________________
Jean R. Rodrigues
Oracle/J2EE Premium Support Engineer
Instrutor Certificado Sun e Oracle (Especialista América Latina)
Certified ScrumMaster
jrodrigues Offline
Posts: 1338
Exato. Essa é a mesma concepção que tenho.
MVC originalmente sempre pretendeu resolver problemas inerentes a camada de apresentação. Portanto, acho ilógico mesclar mais camadas se o problema que deve ser isolado é o da apresentação.
Perfeito. :!:
_________________
Jean R. Rodrigues
Oracle/J2EE Premium Support Engineer
Instrutor Certificado Sun e Oracle (Especialista América Latina)
Certified ScrumMaster
lap_junior Offline
Posts: 914
Eu não mudei de opnião e concordo com o ponto de vista citado pelo Jack mas entendi melhor o ponto de vista do Jean, e como o Vitor citou, como não tem nada que impede de vc aplicar o mvc em um nível maior ou menor, então depende da abordagem.
Na época o Jean postou no JavaRanch tb, seguem os links.
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=002036
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=34&t=003911
flw
_________________
JavaFree.org
Blog
ronaldtm Offline
Posts: 2299
Bem... Model/View/Controller? Em que camada existe uma visualização se não na de apresentação? (views de bancos de dados não contam
De maneira simples, padrões são soluções bem testadas para problemas em contextos repetidos. O MVC foi bem testado para coordenação de componentes visuais. Você pode tentar usá-lo em outros contextos, mas fique avisado que ou isso não foi bem testado, ou foi testado e não funcionou muito bem...
Aliás, a idéia de MVC para web é relativamente nova, apenas uma adaptação do MVC original do Smalltalk, já que o paradigma web (http) não suporta notificações do mesmo modo que componentes GUI.
E o que são a camada de Controle e 'a Model'? É claro as camadas devem ser definidas visando coerência e dependem do tipo de sistema, isto é, cada um cria as camadas que achar necessário, mas pelo menos hoje em dia, em sistemas corporativos J2EE, as camadas mais comuns são Apresentação, Negócio, Integração e Persistência (sendo que as últimas muitas vezes são combinadas em uma só). "Controle" se encaixaria melhor em um contexto de subsistemas ou componentes, pois envolve coordenação e notificação, conceitos que, ao meu ver, não mesclam muito bem com divisão em camadas. "Model" poderia ter como correspondente a camada de persistência, já que no MVC o Model é quem guarda as informações de estado. Porém, "persistência" tem um significado definido, mas o que é o "model", num contexto de uma aplicação corporativa (presumo que este seja o contexto, já que este é o mais apropriado para separação em camadas)?
vfpamp Offline
Posts: 6009
View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.
Eu defendo a idéia de que a View que o pattern fala não é uma UI com usuário, é uma Interface com alguma coisa. Por exemplo um WebService pode ser um View. Assim se eu separar o meu modelo de dados para permitir uma independência de metodologia de persistência, eu posso criar uma view para que outras aplicações acessem a minha API, que irá retornar os dados do jeito que eles desejarem
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
ronaldtm Offline
Posts: 2299
Corretíssimo. Porém, o Swing herda muito do MVC original. A separação entre view e controller é feita de modo implícito, já que é possível se estender o controller (por meio de tratamento de eventos) e se ter mais de uma view para um model. Esta flexibilidade demonstra um desacoplamento razoável entre os dois, apesar de serem implementados na mesma classe. Então, acho justo afirmar que o Swing segue a filosofia do MVC na implementação de seus componentes.
Mas a separação mais usual atualmente, no contexto de uma aplicação web, é apresentação, negócio e persistência.
brunoambrozio Offline
Posts: 529
Galera está dando um nózão na cabeça!!!!!!!!!!! hehehehhe
Poderiam fazer um resumo de td isso?????????????
_________________
Bruno Brigantini Ambrózio
Consultor SAP Netweaver
SCJP, SCWCD
Softtek do Brasil - www.softtek.com
JavaFree.org
ronaldtm Offline
Posts: 2299
Renders, presented, presentation... apresentação?
Um webservice por definição é stateless. Os frameworks MVC usados para web servem para guardar a lógica de navegação entre as páginas de uma aplicação. Navegação pressupõe estado. Apesar de usar o protocolo http para comunicação, webservices são acessados diretamente pela aplicação cliente, sem a necessidade de passar por um controlador responsável pela decisão do fluxo, pois não há fluxo. Você até pode configurar um webservice no Struts, mas isso é só um workaround, pois um webservice não deveria necessitar de navegação anterior ou posterior à sua execução.
Isso é só a separação da camada de persistência, não tem nada a ver com MVC.
O que é essa view? As aplicações irão ler e preencher formulários, pra depois clicar em botões para chamar seu webservice?
O que você descreve é uma API, uma interface de programação. Parâmetros de entrada, dados de saída. A única diferença é que o protocolo de comunicação entre as aplicações não é RMI, ou chamadas locais de métodos, mas XML sobre HTTP.
vfpamp Offline
Posts: 6009
Digamos o seguinte...
Tenho uma aplicação J2EE GIGANTE!
E quero que a minha aplicação faça a persistência tanto em banco de dados quanto em um Prevayler da vida, tudo configurado por um arquivo XML
Sendo assim, eu monto uma equipe que cuida somente da camada de persistência, como gravar, restaurar, transformar em objetos e devolver para a lógica.
Então defino métodos de entrada e saída desse framework que será montado, por exemplo:
- insert(Dado qualquerDado);
- update(Dado qualquerDado);
- delete(Dado qualquerDado);
- getDado(OQL oql);
- addClassListener(ClassListener listen)
....
Então a classe que mantém esses métodos será a view, pois ele é a fronteira do meu framework.
Teremos outras classes cuidando da persistência, da lógica de buca e atualização que poderão ser dividadas entre Controle e Modelo propriamente dito
Sacaram??
Que tal, to viajando??
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
vfpamp Offline
Posts: 6009
Não posso apresentar somente um conjunto de métodos ??
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
ronaldtm Offline
Posts: 2299
Mas daí seria apenas uma separação em subcamadas. A definição da interface é só um passo para esta separação: "interfaces bem definidas".
A lógica de busca e atualização em um controlador eu até entendo, mas também seria uma separação em subcamadas. E o modelo, onde entra, já que a persistência já está sendo cuidada por outras classes? Seria o outro lado da fronteira (o que chama)?
Além do mais, o exemplo que você deu contém múltiplos modelos, e não "views" ou "controladores". O modelo deveria ser único, para manter a consistência dos dados, não?
vfpamp Offline
Posts: 6009
Deixa eu me expressar melhor.
Pegando o método getDado(OQL oql); por exemplo. A OQL (Object Query Language) é uma SQL da vida, só que para objetos. Quem vai processar a OQL para saber que tipo de dado o desenvolvedor necessita?
O Controller
A View seria a classe de entrada dessas chamadas, irá dispor um conjunto de regras para que os usuários a utilizem, como um formulário HTML
O Model seria os dados propriamente ditos juntamente com as classes de dados e o banco de dados.
PS: Nunca fiz uma arquitetura assim, estou falando como eu faria uma dessas
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
ronaldtm Offline
Posts: 2299
Você vai implementar todo um framework JDO-like? Boa sorte...
Não seria melhor uma combinação TO/DAO/AbstractFactory? O DAO encapsula a lógica de persistência, recebendo apenas TOs. Assim, não seria preciso trabalhar com OQL (e fazer um parser, um interpretador, um conversor pra SQL) na aplicação, somente no DAO. E para escolher entre as implementações do DAO (para relacional, objeto, xml, etc), use uma fábrica abstrata configuravel. Ou você realmente quer fazer um JDO personalizado? A propósito, para a implementação deste tipo de framework existem padrões específicos (conhecidos, testados e aprovados pelo teste do tempo), você não precisa tentar usar MVC...
hein? API com front-end HTML? Não entendi.
isso pra mim são: Camadas, TOs e DAOs, talvez BusinessObjects, e não Controllers e Models.
ainda bem. =P
Sério, vocês estão tentando empurrar MVC onde ele simplesmente não se encaixa, tratando outros padrões como se fossem MVC.
Padrões existem como soluções repetidas para um determinado problema, em um determinado contexto. Alguns padrões são aplicados em contextos mais genéricos (Adapter, Proxy, Composite) e podem ser usados em várias ocasiões. Outros são bem específicos para uma determinada função, talvez em um determinado tipo de aplicação (SessionFaçade, DAO, TransactionScript), simplesmente não cabendo em outros contextos.
Muda-se o contexto, procura-se um padrão que se encaixe neste novo contexto, não se usa à força um outro padrão impróprio, só porque este já lhe é familiar.
vfpamp Offline
Posts: 6009
Como eu disse, é uma aplicação J2EE GIGANTE
É claro que iria usar outros padrões e outros frameworks para compor uma solução. Mas a integração disso tudo para mim, está bem claro, é MVC
Como eu disse antes, a view para mim não é uma tela. É simplesmente a classe que encapsula o framework
Apropósito, o DAO ficaria fora desse framework
Pattens são soluções para um problema, não são implementação.
Problema relacionado ao MVC: applications need to support multiple types of users with multiple types of interfaces
Um framework pode ter vários métodos de entrada e saída (Que seja AbstractFactory). Vários controllers e diferentes Models.
Eu poderia usar o Hibernate como Controller + Model
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
jrodrigues Offline
Posts: 1338
Exato.
É isso que acontece hoje em dia.
Todo mundo acha que MVC se aplica a qualquer arquitetura.
Além do mais, temos diversos tipos de MVC e nem entramos no mérito:
- MVC I
- MVC II
- Pull-MVC
...
MVC NÃO é a arquitetura que "integra" ... caso comtrário vamos ter objetos de negócio relacionados a apresentação complementamente inchados e sem coesão alguma.
Além do mais, isso simplemesmente tornará o acoplamento entre as camadas muito mais forte ... o que simplesmente pode inflexibilizar modificações na arquitetura do sistema.
Dificuldade para manutenção e para escalar horizontalmente advém de designs assim.
_________________
Jean R. Rodrigues
Oracle/J2EE Premium Support Engineer
Instrutor Certificado Sun e Oracle (Especialista América Latina)
Certified ScrumMaster
ronaldtm Offline
Posts: 2299
E o HTML que você mencionou, era pra quê?
O contexto, você está esquecendo do contexto...
É isso aí: applications need to support multiple types of users with multiple types of interfaces, isto é, user interfaces.
Você devia rever o seu conceito de MVC e padrões. Dê uma lida na página do link do meu primeiro post, lá vai ter uma descrição do MVC no Smalltalk: http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
Outras páginas, um pouco mais digeríveis:
http://ootips.org/mvc-pattern.html e http://www.object-arts.com/EducationCentre/Overviews/MVC.htm
ricardo.landim Offline
Posts: 86
Ae galera... pelo que entendi a coisa fica mais ou menos assim...
está faltando alguma coisa ou é isso mesmo ?
_________________
Mais importante que o CONHECIMENTO é o que se pode fazer com ele!
ronaldtm Offline
Posts: 2299
Pode ser assim.
Digo e repito: não há um único jeito correto de se fazer um design. Se houvesse, nós projetistas estaríamos desempregados...
vfpamp Offline
Posts: 6009
Eu não sei se eu estou certo ou errado fazendo isso, mas eu to elevando o conceito de MVC a um nível que vcs não estão vendo
Deixa eu ficar na view que o foi o foco da ultima discussão.
No conceito normal do MVC, como é descrito:
View - Interface com Usuário, HTML, UI do Swing/SWT/AWT.
No meu conceito:
Usuário = Desenvolvedor dos processos do cliente.
View - Classe(s) ( facade
Assim:
Model: Qualquer coisa que define qualquer coisa
Controler: Qualquer coisa que mexe nas definições de uma coisa.
View: Qualquer coisa que represente uma integração com uma outra coisa fora do escopo da coisa ao qual o MVC foi aplicado.
PS: As vezes eu não sei de onde eu tiro essas coisas
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
ricardo.landim Offline
Posts: 86
correto ronald...
só estou querendo ter uma ideia de um sistema "genérico"...
com certeza nunca iremos encontrar um projeto padrão que se encaixe em todos os nossos problemas mas ter a ideia de um correto eu acho que já facilita a adaptação deste para outros... sendo assim, o resultado de cada projeto pode servir de analise para execução de outros, e outros e assim por diante !!!
_________________
Mais importante que o CONHECIMENTO é o que se pode fazer com ele!
ronaldtm Offline
Posts: 2299
Elevando não, baixando, já que a camada de persistência é a última
É... =P
É que isso é só mais uma divisão das camadas, entenda-me... Não existe mais o "triângulo" de interações entre os componentes, mas sim a dependência em relação à camada imediatamente inferior, isto é, padrão Layers.
jack_-_ganzha Offline
Posts: 4133
Erhm... será que essa discussão vai descambar para 6 paginas tambem?! Bom, eu creio que no forum do JavaRanch foram dadas otimas respostas que demonstram o carater multi tier do MVC. Dentre elas, as que achei mais interessantes foram as seguintes:
No fim das contas essas opiniões refletem bem o que eu penso sobre MVC, em especial, a afirmação de que "cada uma de suas 3 camadas pode ser, ela mesma, composta de varias outras camadas".
valeuz...
_________________
Marcos Silva Pereira
http://marcospereira.wordpress.com
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (Fowler)
jack_-_ganzha Offline
Posts: 4133
Ah, sim, Vitor, passa um pouco desse treco pra cá!
valeuz...
_________________
Marcos Silva Pereira
http://marcospereira.wordpress.com
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (Fowler)
vfpamp Offline
Posts: 6009
Caraca...
É isso que eu queria dizer... podemos ter sub-MVCs
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
ronaldtm Offline
Posts: 2299
Mas veja que eles citam o MVC apenas na arquitetura e na camada de apresentação, não na camada de persistência.
vfpamp Offline
Posts: 6009
Hum... isso:
So your presentation tier can itself contain a multitier architecture, and so can your model.
Não está dizendo que posso ter no model um MVC?
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
ronaldtm Offline
Posts: 2299
Hehe Não, tá dizendo que você pode ter sub camadas no model. Pelo menos, isso é o que eu entendo por multi tier (no babylon, Tier: fila, fileira, renque; alinhamento; ordem. Renque: tier, layer).
E ele só cita o MVC na camada de apresentação:
marcomidia Offline
Posts: 2
Galera, estou chegando atrasado para a discussão, mas acho que pode ser válido, abaixo um resumo de toda discussão:
Camada de Persistência - Data Access Object(DAO)
Camada de Negócios - Businnes Objects(BO)
Camada de Modelo - Data Transfer Object(DTO)/Value Object(VO)
Camada de Modelo Resumido - Session Façade
Camada de Controle - Controller(Actions Forms)
Camada de Visualização - View
Notem que o MVC sozinho não seria o melhor padrão a ser adotado, ele foi desenvolvido para ser acoplado a outros padrões...como o DAO, Façade, BO....
A princípio se fossemos listar apenas os itens referentes ao MVC teríamos:
Camada de Modelo - TO + BO + DAO
Camada de Controle - Controller(Actions Forms)
Camada de Visualização - View
Notem que para viver só de MVC é necessário forçar a barra na camada Modelo...por isto, procurem adotar outros padrões para facilitar na hora do desenvolvimento.
Miojo, Jean, lap_junior, concordam?
[]'s
_________________
Marcomídia!
Relacionados
Spring avança na briga contra o EJB? http://javafree.uol.com.br/topic-851610-Spring-avanca-na-briga-contra-o-EJB.html MVC X STRUTS http://javafree.uol.com.br/topic-14132-MVC-X-STRUTS.html Duvidas http://javafree.uol.com.br/topic-854643-Duvidas.html MVC - PADROES - Criando um para APLICACOES DESKTOP http://javafree.uol.com.br/topic-863044-MVC-PADROES-Criando-um-para-APLICACOES-DESKTOP.html MVC http://javafree.uol.com.br/topic-853239-MVC.html Conceitos http://javafree.uol.com.br/topic-856206-Conceitos.html MVC e MVC2 http://javafree.uol.com.br/topic-5477-MVC-e-MVC2.html O QUE É Struts http://javafree.uol.com.br/topic-6026-O-QUE-É-Struts.html Arquitetura http://javafree.uol.com.br/topic-868916-Arquitetura.html