MVC (Desktop) - Dúvida de interação!

Programação Arquitetura
#1

Boa Noite! :smiley:

Há alguns dias, pesquisei muito sobre o MVC (desde sua aplicação no Smalltalk até hoje em aplicações Java). Surgiram, então, dúvidas cruéis sobre a interação das partes na hora de sua implementação (em Desktop). Observe as duas imagens em anexo neste tópico.

Baseado no conceito de: “Desacoplar as partes do MVC de forma que ao precisar trocar ou modificar uma das parte isso não influenciará em modificações nas demais partes, tornando assim o sistema escalável e com maior facilidade de manutenção.” Como tornar isso implementável?

Como exemplo vamos imaginar um sistema de cadastro qualquer, sem persistencia, dividido em MVC (Modelo, Visão e Controle).

Surgem então as perguntas:

  1. O main, deverá chamar quem (instaciar): O Controle e/ou a Visão e/ou o Modelo?
  2. O Controle interage com quem? (instancia Modelo e/ou Visão?) De que forma?
  3. A Visão interage com quem? (instancia Controle e/ou Modelo?) De que forma?
  4. Quando o Modelo for alterado, quem vai alterar a Visão? De que forma? (Visão vai instanciar Modelo??? como implementar)
  5. Restrições de dados inválidos (tipo inválido de dado para um atributo do modelo) serão bloqueados na Visão?
  6. Como estamos baseados em um cadastro, o métodos CRUD ficarão no Controle?
  7. Quem vai avisar a Visão se uma das 4 operações do CRUD foi executada com sucesso ou não?

Respondida as perguntas, questiono: Olhando agora as respostas, o sistema realmente será implementado no padrão MVC a tal modo de poder a qualquer momento, baseado no conceito citado acima, passa-lo para WEB simplesmente trocando a minha Visão(GUI)?

Para fechar, observando as imagens em anexo deixo mais duas perguntas:
8- No View, observa-se a citação “Renderiza o Model”. O que é isso?
9) Qual seria o caminho (fluxo) feito pelo sistema de cadastro se eu quiser agora alterar dados que já estão no Modelo?
10) Para um Modelo ser um Bean, ele precisa ter obrigatoriamente um construtor vazio?

Felicidades a todos do fórum, sou novo aqui e espero poder compartilhar com todos informações de interesse geral. Um feliz 2009 com bastante saúde e sucesso. Obrigado! :thumbup:



#2

Oi, bem vindo! Vou tentar contribuir com meus 2 cents, vamos lá:

Surgem então as perguntas:

Por ‘Main’, tu entende pela parte do programa que irá criar a janela principal, então você está se referindo a desenvolvimento Desktop? Anyway, isso não está ligado ao MVC, então vamos para a próxima questão.

O Controle é responsável por tratar as ações/eventos lançadas pela view! O Controller é o fiel escudeiro da View. Ela o invoca.

Sim, com o Controle. Digamos assim: A view conhece o seu controller e observa o modelo.

Em um mundo perfeito, há o conceito de binding de componentes do modelo com a visão, fazendo com que uma alteração no modelo reflita automaticamente na view. Então a resposta correta é o modelo, dentro do MVC. -sim, o controlador pode influenciar no sentido de dar uma “ajudinha” ao modelo chegar até a view-

Isso já é responsabilidade do seu domain-model. Em tese, é interessante manter estas regras em ambos os lados.

Apesar de isso nao ter ha ver com MVC, e como tu ja sabe que o controller apenas deve tratar eventos e delegar chamadas… o CRUD é responsabilidade dos DataMappers, DAOs, Repositorios, Services, etc. (ai é um papo ha ver com camadas e não com mvc)

Quem for responsável pelos eventos. Tu pode utilizar o controller então, mas querendo ou não, quem provocou a ação de ‘sucesso’ ou ‘fracasso’ foi o modelo.

Respondida as perguntas, questiono: Olhando agora as respostas, o sistema realmente será implementado no padrão MVC a tal modo de poder a qualquer momento, baseado no conceito citado acima, passa-lo para WEB simplesmente trocando a minha Visão(GUI)?
No mundo dos ursinhos carinhosos sim. Mas é claro que sempre há uma ou outra adaptação. Principalmente no controller, que é o mais visado pelos frameworks mvc que sempre armam uma forma de suja-lo com alguma annotation, classes próprias, herança, etc.

Para fechar, observando as imagens em anexo deixo mais duas perguntas:

Sim, a view representa o estado do model, nada mais justo então.

O normal do MVC: view chama action “update” o controlador identifica o que a view quer, pega o objeto e delega para o serviço que fará a persistência/modificação do dado e então, a view é atualizada conforme alteração (depende muito aqui, se for atualizar uma lista, uma tela, etc.), mas lembre-se é atualizada conforme o modelo.

É recomendável, mas não precisa necessariamente. Tu queria falar de POJOs?

Acho que outras pessoas responderão melhor suas duvidas, não sei se te deixei mais confuso, mas era isso. abraço

Links interessantes:

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

#3

:arrow: Fala Peerless, um abraço para todos aí de Rio Grande do Sul!
Primeiramente quero agradecer muito sua atenção e o tempo dispensado em ajudar neste tópico. Muito Obrigado, são 2 cents valiosos! :smiley:

Vamos lá, suas respostas também levantaram outras dúvidas, com certeza chegaremos lá.

1) O main, deverá chamar quem (instaciar): O Controle e/ou a Visão e/ou o Modelo?
Re: Por ‘Main’, tu entende pela parte do programa que irá criar a janela principal, então você está se referindo a desenvolvimento Desktop? Anyway, isso não está ligado ao MVC, então vamos para a próxima questão.
Dúvida: Sim, Desktop. Ok, “main” não faz parte do MVC. Mas é a partir dele que devo iniciar a execução da aplicação, estou certo? Se sim, ele vai chamar inicialmente qual das camadas do MVC? (O Modelo, o Controle ou Visão?)

2) O Controle interage com quem? (instancia Modelo e/ou Visão?) De que forma?
Re: O Controle é responsável por tratar as ações/eventos lançadas pela view! O Controller é o fiel escudeiro da View. Ela o invoca.
Dúvida: Ok. Ela que você diz é a Visão? A Visão invoca o controle? Mas e o Modelo quem invoca?

3) A Visão interage com quem? (instancia Controle e/ou Modelo?) De que forma?
Re: Sim, com o Controle. Digamos assim: A view conhece o seu controller e observa o modelo.
Dúvida: “A view conhece o Controle”, beleza, Ok. “e observa o Modelo”? Como a Visão observa o Modelo? Como isso seria implementado?

4) Quando o Modelo for alterado, quem vai alterar a Visão? De que forma? (Visão vai instanciar Modelo??? como implementar)
Re: Em um mundo perfeito, há o conceito de binding de componentes do modelo com a visão, fazendo com que uma alteração no modelo reflita automaticamente na view. Então a resposta correta é o modelo, dentro do MVC. -sim, o controlador pode influenciar no sentido de dar uma “ajudinha” ao modelo chegar até a view-
Dúvida: Só para ficar claro, e manter o desacoplamento na implementação, seria certo então passar pelo Controle, ou seja, o Controle conhece o Modelo e conhece a Visão. Qualquer alteração realizada no Modelo o Controle fielmente altera na Visão, correta a afirmação?

6) Como estamos baseados em um cadastro, o métodos CRUD ficarão no Controle?
Re: Apesar de isso nao ter ha ver com MVC, e como tu ja sabe que o controller apenas deve tratar eventos e delegar chamadas… o CRUD é responsabilidade dos DataMappers, DAOs, Repositorios, Services, etc. (ai é um papo ha ver com camadas e não com mvc)
Dúvida: Desculpe essa pergunta foi mal elaborada por minha parte, como eu mesmo havia dito não queria ainda entrar na parte de persistencia. Na verdade a pergunta seria: Onde coloco os métodos alterar, inserir, consultar, excluir do cadastro dentro do MVC. Ou seja, a regra de negócio ficará no Controle ou no Modelo?

9) Qual seria o caminho (fluxo) feito pelo sistema de cadastro se eu quiser agora alterar dados que já estão no Modelo?
Re: O normal do MVC: view chama action “update” o controlador identifica o que a view quer, pega o objeto e delega para o serviço que fará a persistência/modificação do dado e então, a view é atualizada conforme alteração (depende muito aqui, se for atualizar uma lista, uma tela, etc.), mas lembre-se é atualizada conforme o modelo.
Dúvida: OK. Nesse caso tú imaginou que os dados já estavam disponíveis inicialmente na Visão para serem modificados. Então pergunto: Qual seria o fluxo que o sistema fará para trazer os dados contidos no Modelo até a Visão, para serem alterados?

Agradeço pelos links auxiliares no tema, realmente VC selecinou um muito bom que é o do fragmental (já havia estudado anteriormente, ele deixa claro o que é MVC e o que são as 3 camadas). Gostei muito do link do POJO, esse valeu mesmo!

Fico no aguardo peerless por mais resposta! Assim como de todos do GUJ. Obrigado! :thumbup:

#4

Oi, tnks! Vamos lá…

[quote]1) O main, deverá chamar quem (instaciar): O Controle e/ou a Visão e/ou o Modelo?
Re: Por ‘Main’, tu entende pela parte do programa que irá criar a janela principal, então você está se referindo a desenvolvimento Desktop? Anyway, isso não está ligado ao MVC, então vamos para a próxima questão.
Dúvida: Sim, Desktop. Ok, “main” não faz parte do MVC. Mas é a partir dele que devo iniciar a execução da aplicação, estou certo? Se sim, ele vai chamar inicialmente qual das camadas do MVC? (O Modelo, o Controle ou Visão?)[/quote]
Sim, se tratando de desktop, em algum momento tu terá um Main que vai chamar a aplicação. Utilize o Main para inicializar teus contextos (se houverem), e, claro, chamar tua interface ( a view ).

[quote]2) O Controle interage com quem? (instancia Modelo e/ou Visão?) De que forma?
Re: O Controle é responsável por tratar as ações/eventos lançadas pela view! O Controller é o fiel escudeiro da View. Ela o invoca.
Dúvida: Ok. Ela que você diz é a Visão? A Visão invoca o controle? Mas e o Modelo quem invoca? [/quote]
Sim, é a visão que chama o controle. O controle tratará de invocar/delegar o necessário para o modelo ou qualquer serviço que possa atualiza-lo/recupera-lo.

[quote]3) A Visão interage com quem? (instancia Controle e/ou Modelo?) De que forma?
Re: Sim, com o Controle. Digamos assim: A view conhece o seu controller e observa o modelo.
Dúvida: “A view conhece o Controle”, beleza, Ok. “e observa o Modelo”? Como a Visão observa o Modelo? Como isso seria implementado?[/quote] Não tão ideal quanto ao mvc do smalltalk, onde a comunicação é via mensagens. Mas, fora de um estado de “binding” implementado por alguns frameworks, como o JSF… visão observa o estado do modelo, qualquer alteração do modelo deve ser refletida na view, o controller pode ‘ajudar’ o modelo a atualizar a view, por ex: recuperando o Objeto e atualizando algum atributo da view com base nele. Mas isso não é o ideal, como já disse, o ideal é utilizar um framework que ‘encapsule’ este trabalho.

[quote]4) Quando o Modelo for alterado, quem vai alterar a Visão? De que forma? (Visão vai instanciar Modelo??? como implementar)
Re: Em um mundo perfeito, há o conceito de binding de componentes do modelo com a visão, fazendo com que uma alteração no modelo reflita automaticamente na view. Então a resposta correta é o modelo, dentro do MVC. -sim, o controlador pode influenciar no sentido de dar uma “ajudinha” ao modelo chegar até a view-
Dúvida: Só para ficar claro, e manter o desacoplamento na implementação, seria certo então passar pelo Controle, ou seja, o Controle conhece o Modelo e conhece a Visão. Qualquer alteração realizada no Modelo o Controle fielmente altera na Visão, correta a afirmação?[/quote]
Sim, correto. Num mundo não perfeito com base em tudo que eu ja disse.

[quote]

6) Como estamos baseados em um cadastro, o métodos CRUD ficarão no Controle?
Re: Apesar de isso nao ter ha ver com MVC, e como tu ja sabe que o controller apenas deve tratar eventos e delegar chamadas… o CRUD é responsabilidade dos DataMappers, DAOs, Repositorios, Services, etc. (ai é um papo ha ver com camadas e não com mvc)
Dúvida: Desculpe essa pergunta foi mal elaborada por minha parte, como eu mesmo havia dito não queria ainda entrar na parte de persistencia. Na verdade a pergunta seria: Onde coloco os métodos alterar, inserir, consultar, excluir do cadastro dentro do MVC. Ou seja, a regra de negócio ficará no Controle ou no Modelo?[/quote]
As regras de negócio ficam no seu domínio de modelo. O trabalho do controlador neste caso é chamar o método do modelo que irá executar a regra de negócio X, Y, Z passando os parâmetros necessários em questão.

[quote]9) Qual seria o caminho (fluxo) feito pelo sistema de cadastro se eu quiser agora alterar dados que já estão no Modelo?
Re: O normal do MVC: view chama action “update” o controlador identifica o que a view quer, pega o objeto e delega para o serviço que fará a persistência/modificação do dado e então, a view é atualizada conforme alteração (depende muito aqui, se for atualizar uma lista, uma tela, etc.), mas lembre-se é atualizada conforme o modelo.
Dúvida: OK. Nesse caso tú imaginou que os dados já estavam disponíveis inicialmente na Visão para serem modificados. Então pergunto: Qual seria o fluxo que o sistema fará para trazer os dados contidos no Modelo até a Visão, para serem alterados?[/quote]
Talvez o construtor do teu controlador trabalhe como um evento “ao abrir” :-), carregue toda informação necessária do modelo e despacha pra view ser atualizada com ela.

Eu sugiro tbm que estude MVP, atende mais o fluxo de dados em sistemas Desktops. Link: http://martinfowler.com/eaaDev/ModelViewPresenter.html

Abraço

#5

Obrigado peerless, entendi a sua idéia!

Com certeza, o correto para existir uma comunicação perfeita entre Visão e Modelo seria usar um framework!
Mas não deixa de estar certo a solução citada acima. O que é muito bom! :smiley:

Uma dúvida: POJO’s podem ter métodos “Adicionar/Remover/Alterar/Consultar” junto com os Gets/Sets? E também podem ter exceções para que no caso do controlador passar algum parâmetro que veio da view inválido (uma data como exemplo - inválido/incompatível com o atributo do POJO) seja avisado ao usuário?
Eu vi e um post no fórum onde alguém cita que já viu esse tipo de uso :shock:

Uma pergunta: Para que a Visão não fique muito acoplada com o Controle que por sua vez não vai ficar muito acoplado ao Modelo, existe solução?
Digo, posso me beneficiar de algum design patterns para isso? Que trabalhe junto na arquitetura MVC?

Realmente já havia escutado falar desse MVP mas como você está indicando, vou me aprofundar no assunto!
Um abração peerless, obrigado novamente! E deixo o convite para todos que quiserem opinar as respostas ou até mesmo responder as questões do primeiro post da forma que imaginam para que fiquem avontade! :thumbup:

#6

[quote=pedromuyala]Obrigado peerless, entendi a sua idéia!

Com certeza, o correto para existir uma comunicação perfeita entre Visão e Modelo seria usar um framework!
Mas não deixa de estar certo a solução citada acima. O que é muito bom! :smiley:

Uma dúvida: POJO’s podem ter métodos “Adicionar/Remover/Alterar/Consultar” junto com os Gets/Sets? E também podem ter exceções para que no caso do controlador passar algum parâmetro que veio da view inválido (uma data como exemplo - inválido/incompatível com o atributo do POJO) seja avisado ao usuário?
Eu vi e um post no fórum onde alguém cita que já viu esse tipo de uso :shock:

Uma pergunta: Para que a Visão não fique muito acoplada com o Controle que por sua vez não vai ficar muito acoplado ao Modelo, existe solução?
Digo, posso me beneficiar de algum design patterns para isso? Que trabalhe junto na arquitetura MVC?

Realmente já havia escutado falar desse MVP mas como você está indicando, vou me aprofundar no assunto!
Um abração peerless, obrigado novamente! E deixo o convite para todos que quiserem opinar as respostas ou até mesmo responder as questões do primeiro post da forma que imaginam para que fiquem avontade! :thumbup: [/quote]

1a. Sim, é claro. O importante é que ele siga sendo apenas um objeto java simples e adicionar comportamento nele não é nada mais que OO.

2a. O MVC está aí pra isso, ele é um padrão arquitetural que serve exatamente para isso. Mas tu pode procurar por outros DPs que auxiliam o processo de “baixo acoplamento” como o Strategy, Inversion Of Control, Dependency Injection, Factory…

#7

Fala peerless ótimo rapaz muito bem explicado! E quero agradecer todo esforço dizendo que suas respostas foram rápidas. Muito legal isso! :smiley:

Deixo uma pergunta: Se você nesse momento que está lendo o post acaba resolvendo fazer um cadastro qualquer, logo pensaria especificamente em quais patterns? Em qual momento você acredita que ele será importante no desenvolvimento?

Em mais, deixo o tópico em aberto para todos que quiserem participar respondendo as perguntas do primeiro post na forma que enxerga o MVC, questionar as perguntas e respostas, tudo aquilo que colabore com o tópico, com certeza muitos iniciantes vão se interessar!

Também quero deixar dois link’s falando sobre MVC e [color=red]gostaria que opinassem sobre eles, quem usa a melhor solução para o nosso caso, como exemplo, um cadastro[/color].

Model-View-Controller (MVC) Structure
Criando uma aplicação em 3 camadas (MVC)

#8

Apenas pra complementar. No Head First: Design Patterns há um capítulo sobre MVC. Eles apresentam MVC como um padrão composto e citam os padrões Composite, Observer e Strategy. No GoF, apesar de não haver exemplos, ele ainda cita outros padrões relacionados, tais como Command e Facade (se não me engano).

O exemplo mostrado no livro é de um “MVC puro” mesmo. O model notifica a view e ela se atualiza a partir disso (utilizando o pattern Observer). Mas eles apresentam, posteriormente, o MVC 2 para Web. Então, sugiro que você leia o livro!

#9

Post duplicado… foi mal.

#10

Opa Wagner. Agradeço muito aí pela dica! :smiley:

Realmente alguns amigos tem aconselhado a entender o MVC 2.
Tenho duas dúvidas:

1b) MVC 2 é o mesmo que o MVP?
2b) Vou criar uma arquitetura que vai rodar somente em Desktop (Swing). Futuramente poderá ser necessária levar o sistema a WEB. Na sua opinião, qual arquitetura melhor será: MVC ou MVC 2 ou outra?

Um abração Wagner, obrigado mesmo pelo apoio! :thumbup:

#11

Pedro,

Estou tentando fazer o mesmo tipo de aplicação que você. Arquitetura com Swing para posterior possibilidade de implantação web. Mas tô meio perdido quanto as implementações. Já andei lendo bastante coisa e até achei alguns materiais interessantes com o Observer:

http://coronet.iicm.tugraz.at/lectures/mmis2/material/slides_mvc.html
http://blog.benhall.me.uk/2006/12/singleton-and-observer-pattern-in-java.html

Queria saber se você conseguiu dar continuidade aí na implementação. Tô pensando em utilizar o Hibernate também para a parte de acesso ao BD.

Vlw
Abs

Alexandre

#12