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 
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.