MVC [conceito]

opa!

se alguem puder me ajudar, ficaria grato

o que é MVC?
Model - View - Controler

http://pt.wikipedia.org/wiki/MVC

no Model??? [ não entendi bem o que faz]

View- é toda a parte de interface com o usuário

Controller - São as classes propriamente ditas, elas que fazem o controle do sistema.

se eu estiver errado, por favor me corrijam e me ajudem a resolver esses problemas de conceito, pois de nada resolve saber “fazer” sem saber o que esta fazendo

e preciso saber também como aplicar e onde, e se alguem puder me mostrar um exemplo ficaria mais grato ainda

abraço

No model… é as classes de acesso ao banco de dados…

No model, é onde você coloca os atributos que geralmente são serializados. Imagine um sistema de cadastro de funcionarios, o model seria mais ou menos assim:

ModelFuncionario

  • nome : String
  • idade : int
  • cargo : String
    (e qualquer outro atributo que voce achar importante)
  • String getNome()
  • int getIdade()
  • void setNome()
  • void setIdade()
    (e os outros métodos de acesso aos atributos)

Você iria inserir os dados que quisesse salvar (nome, idade, cargo…) nos campos do view e quando apertasse um botão de cadastro, quem iria pegar esses dados e colocá-los na sua classe model seria o controller, e depois o controller que iria “mandar” a interface dizer que o funcionario foi cadastrado com sucesso.

É mais ou menos isso…

No model vc tm poderia ter suas classes com regras de negócio…e mais abaixo suas camadas de persistência com banco de dados…
tipo isso…
[]'s

Você que perguntou e todos que responderam estão errados. Eu já respondi uma pergunta parecida em http://www.guj.com.br/posts/list/69833.java#367360

Pra entender porque não é assim. Você vai ter que ler dois livros:
1 - Design Patterns
2 - Patterns of Enterprise Application Architecture

1 curtida

[quote=paulofernandesjr]opa!

se alguem puder me ajudar, ficaria grato

o que é MVC?
Model - View - Controler

http://pt.wikipedia.org/wiki/MVC

no Model??? [ não entendi bem o que faz]

View- é toda a parte de interface com o usuário

Controller - São as classes propriamente ditas, elas que fazem o controle do sistema.

[/quote]

Todas essas partes são na realidade um conjunto de classes. “Classes propriamente ditas” não faz sentido.

O View é o que o cliente do sistema vê. Numa GUI o View é a parte visual. Num webservice, o View é a interface SOAP. O view é aquilo com que o cliente se comunica, seja o cliente humano ou outro sistema.

O Controler é o que dá vida à view. É o mecanismo. A lógica comum. Webservices funcionam sempre da mesma forma. Páginas web tb. Swing tb. etc… Ha um mecanismo instrinseco a toda a View. Isso é o controler.
Se a view é a fachada e o controler é a mecanica onde está a diferença ? No model. O model é aquilo que contém a logica diferente. Num webservice é a sua logica de implementação. Numa UI é o que a aplicação tem que fazer. A trindade MVC não é separável. Não pode ter apenas o M ou o V ou o C ou pares. Têm que ter os três.

O conjunto das classes do M + as do C + as do V formam uma camada em que as informações entram pelo view, são processadas pelo C de forma generica e pelo model de forma especifica e voltam ao view.
O padrão MVC destina-se a resolver uma dependencia ciclica. Esta dependencia é especialmente patente em UI e isso fez dele a base para frameworks de UI como Swing e JSF. Neles vc tem os três tipos da trindade mas apenas o controller é padrão e pré-implementado (porque ele é o mecanismo, é o generico). O View e o Model vc pode alterar. No caso do Swing o model é tudo aquilo que extender as interfaces model, e o view todos os L&F por ai. No JSF o view podem ser JSP ou qualquer mecanismo de renderização , e o model é o Mbean.

Não posso sublinhar o bastante que o padrão MVC não se aplica a camadas mas sim é uma camada em si mesmo. Ele é criado para simplificar a implementação de uma camada. O View é sempre o que comunica com a camada acima e o Model o que comunica com a camada a baixo. o Contoller é a logica da camada em si.

Vamos ver se eu entendi…

[color=red]Model=>[/color] é a parte onde eu faço a logica de acesso a dados, POJO, contendo os gets e sets, e a persistência

[color=red]View=>[/color] é a parte que faz a intersecção entre o usuário e o model, ou outro sistema e o model

[color=red]Controller=>[/color] é a parte que faz a lógica especifica, por exemplo, validar se um metodo pode ser utilizado… e como ele é utilizado.

[color=red]Persistência=>[/color] qualquer forma que realiza a gravação, seja em banco, sessão, arquivo texto, cookie, etc

agora tem outro problema, como que eu interligo isso? não entrou ainda na minha cabeça a interligação desses itens.

PS: se não entendi algum conceito, ou alguem queria complementar, fique a vontade, eu ainda te agradecerei por isso.

abraço

A cada dia que eu mais estudo o MVC, menos o compreendo.

Já vi dezenas de pessoas falando sobre isso (incluindo eu), cada uma com um conceito diferente. Inclusive, eu mesmo tenho uma visão do MVC que poucos compartilham.

O único consenso real que vejo é que a View só mostra, o Model armazena dados e o Controller controla o fluxo.

Mas quando se entra no mérito de como transformar estes conceitos vagos em código, aí a coisa fica muito diferente. Cada um diz uma coisa e no fim das contas ninguém diz nada.

1 curtida

Eu pelo menos faço assim: no controller, eu tenho alguma coleção (ou uma única entidade) do model e um objeto do view. Sempre que você faz algo no view(interface do programa), o controller recebe a requisição, faz o processamento usando os dados do model e envia o resultado pro view exibir.

Em um único programa, você pode ter várias dessas triades (model, controller e view de funcionário, aula, universidade, e aluno, por exemplo, em um sistema para uma universidade). Isso daria pelo menos 12 classes. Para a comunicação dos dados de funcionario e aula, os controllers das duas deveriam se comunicar para transmitir os dados.

A comunicação quase sempre ocorre entre os controles (com várias exceções) e só os controle tem os seus models e views (com várias exceções também :)). Usando o exemplo de antes: no model universidade, você poderia ter como atributo uma coleção do model de funcionario, aula e aluno (uma universidade tem vários professores, aulas e alunos). No model de aula, teria uma coleção de aluno e um professor (uma aula tem vários alunos e um professor). Mas aluno e professor não teriam nenhuma coleção dentro deles.

Não sei se esse é o jeito correto ou não, mas tem funcionado muito bem pra mim :slight_smile:

Mas pergunta para aquele Leonardo3001. Já que ele disse que todos responderam errado, e ele certo, ele deve ser o cara! Se continuar com duvidas, me passa seu e-mail que eu mando algo que eu já tenho feito esplicando a minha idéia sobre esse assunto.