Duvida MVC

Pessoal, tou iniciando em UML e já dei uma boa lida sobre MVC. Estou fazendo um trabalho sobre sistema de rfid, similar a um controle de acesso e preciso aplicar o mvc.
Pelo que entendi eu aplico o view na visualização do sistema, exibição que utiliza o padrão strategy. O modell na estrutura do sistema como os cadastros etc que utiliza o padrão obsorver. e o controler nas funcionalidades do sistema que tbm utiliza o padrão strategy.
Coloquei em anexo o diagrama de classes que fiz do sistema.
não sei se meu raciocínio ta certo, se alguém puder ajudar agradeço.


Model-view-controller

Model - representação dos elementos do seu domínio e interação com as ferramentas de persistência
(Classes com atributos e métodos)
View - Interface com usuario(Swing, JSP).
Controller - Controle da regra de negócio.

Não entendi a tua interface View e nem o que é Controller pra ti.

O Controller atua como intermediário entre View e Model. Num modelo MVC perfeito, Model notifica View. As interações do Usuário (com o componente View) faz com que a View se comunique com o Controller. O Controller é que altera o Model nesse caso. Tem vários design patterns que vc pode aplicar partindo disso. O padrão Observer talvez seja o mais óbvio. Tuas View atuam como observers e o Model é o subject (observable). O padrão Composite normalmente é aplicado na interface gráfica (a própria API do Swing faz isso, por exemplo, com os componentes de Menu). O padrão Command normalmente é utilizado junto aos controladores pra encapsular uma solicitação em um objeto. O padrão Strategy a que tu se referiu é porque a View atua para o Controller como um Strategy. Você pode ter algoritmos intercambiáveis representando a View e o Controller deveria ser flexível a ponto de permitir isso.

Na hora de implementar talvez vc sinta a necessidade desse controller. Mas lembre-se de não jogar as regras de negócio nele e muito menos o acesso aos dados. :smiley:

Falou.

Obrigada pelas respostas pessoal. Acho que agora entendi: os controllers chamam os metodos correspondentes tipo o excluir chama o id correpondente (ClienteID) …e as views é onde visualizo os dados em formulário. Anexei um novo diagrama de classes que fiz. Espero que esteja de acordo agora :).


Pra ser sincero não entendi tão bem o teu diagrama. :smiley:

Eu acho que tem uma coisa que tem que deixar claro (e que foi discutido um montão de vezes no fórum de Arquitetura de Sistemas): MVC não é divisão em camadas. Se você procura por um bom design, antes de mais nada é melhor utilizar um modelo que separe as camadas. O que se faz normalmente é prover uma camada de negócios, uma de persistência e uma de apresentação. Nem tudo pode ser representado através de um conceito de negócio, normalmente um cadastro, por exemplo, é feito por algum serviço. Ou seja, quando o usuário, interagindo com a camada de apresentação, decide cadastrar um cliente, você utiliza um serviço (por exemplo, ClienteService) o qual cria o Cliente e delega para uma camada de persistência a realização da persistência do objeto (muitas vezes por meio de um DAO). Onde entra o MVC nisso? Se você quiser utilizá-lo, vai empregá-lo na camada de apresentação. Acontece que o que você deseja que sua View represente está nas outras camadas (se você tiver mais camadas). Basicamente, o que acontece, o usuário interage com um componente View, um Controller acessa o modelo (provavelmente, num caso de cadastro ele acessa um serviço) e esse serviço se comunica com as demais camadas:

CadastroDeClienteView -> AlgumController -> ClienteService (faz o cadastro do cliente, delega a persistência para outra camada).

Partindo disso, duas possibilidades. Ou a View realmente está observando o modelo a ser alterado por meio de um padrão como o Observer e ela se altera com base nisso, ou o Controller modifica a View (acho que isso é mais utilizado, apesar de descaracterizar um pouco o MVC “puro”).

Tem zilhões de arquiteturas e padrões e o ideal é analisar sempre. O que lhe passei foi um esboço do que tenho mais visto por aí e que utilizei nos projetos que fiz/participei.

Abraço!

Vamos ver se entendi: para cada formulario eu vou ter uma view e no controlador vou ter os métodos deste form?
por exemplo vou ter um controlador e uma view para cadastro cliente outro para cadastro veiculo?
Anexei a maneira como fiz. Ficou bem mais organizada!!!
Abraços


E ai daniweb, bem vinda ao forum.

Vc já sabe se o seu sistema será web, swing, os dois juntos ou etc…?

É vc mesma que irá codificar ou irá passar para outras pessoas codificarem?

flws

brigada! por enquanto swing por questões de segurança!
eu mesma vou codificar!

Oi dona Dani.

Primeiro, MVC é um padrão mas na minha opinião na maioria das vezes tem que ser encarado como um conceito.

A sua idéia no geral sobre o conceito acho que tá no caminho certo; o problema é quando a gente olha para o seu desenho.

Posso estar errado, mas os teus desenhos tem a cara e o jeito de andar client x server. Estas classes Funcionario, Client, estas letras maiúsculas no começo dos métodos a repetição dos nomes na classe e no método em forma de alto afirmação…

Se for pra fazer alguma coisa client x server e não orientada a objetos então vai ficar realmente bem próximo a isso que vc desenhou, ou seja, talvez nem precise de um modelo UML, o treco envolve apenas 2 classes (CadastroFuncionarioPresenter, Funcionario) e talvez mais algumas de infra (conxões, helpers, etc…) que não estão demonstradas. Quem irá se perder com uma idéia simples assim? Lembrando que UML não faz com que seu sistema seja orientado a objetos.

Fala mais coisas para nós:

  1. Vai ser client x server?
  2. Como você vai lidar como a persistencia dos dados? (JDBC, Hibernate, JPA, iBates, JDO, EJB, etc…)
  3. Vc pretende fazer alguma coisas mais orientada a objetos?
  4. Que tipo de linguagem vc domina? (A resposta desta pergunta serve para sabermos com que tipo de arquitetura vc está acostumada)

flws

olá fantomas.

De início: este projeto é um trabalho de conclusão de curso. Estou desenvolvendo um estudo de caso para um estacionamento então é algo que realmente precisa ser aperfeiçoado. Eu tentei fazer da melhor maneira, pois estou começando agora a ver patterns, mais vou trabalhar para melhorar. Uma das fontes que usei: http://www.javafree.org/artigo/871446/Apresentando-ModelViewPresenter-o-MVC-focado-na-visualizacao.html
a questão de UML é para ter uma melhor visão e erros do sistemas e é essencial pelo curso que estou fazendo de engenharia de software. Quanto ao desenho fiz foi apenas um esboço para ver se ta certo a lógica, não usaria forms por ex e sim janelas. Mais o que vc sugere que modifique?como disse tou iniciando estudos em mvc. :slight_smile:
Quanto as perguntas:
1.Não, por enquanto.
2.phpDesigner2008.
3.Concerteza.
4. Dominar ainda não, sei o básico de PHP e um pouco de javascript.
obs. este é meu segundo projeto, o primeiro foi de um sistema de gerenciamento usando a IDE Dephi for PHP.
Agora eu pergunto: O que estou errando? :?:
flw

[quote=Daniela]De início: este projeto é um trabalho de conclusão de curso. Estou desenvolvendo um estudo de caso para um estacionamento então é algo que realmente precisa ser aperfeiçoado. Eu tentei fazer da melhor maneira, pois estou começando agora a ver patterns, mais vou trabalhar para melhorar. Uma das fontes que usei: http://www.javafree.org/artigo/871446/Apresentando...VC-focado-na-visualizacao.html
a questão de UML é para ter uma melhor visão e erros do sistemas e é essencial pelo curso que estou fazendo de engenharia de software. Quanto ao desenho fiz foi apenas um esboço para ver se ta certo a lógica, não usaria forms por ex e sim janelas. Mais o que vc sugere que modifique?como disse tou iniciando estudos em mvc.[/quote]

Então Dani…aqui no forum tem bastante gente que tem a visão academica, outras que tem a visão academica junto com bastante tempo no mercado de TI, tem aqueles que são auto didatas e outros que tudo isso junto. Logo as vezes as visões podem ser um pouco diferente, normalmente a visão de quem está no mercado é um pouco mais complexa porque o individuo está (e tem que estar) preocupado com um montão de situações para garantir que o treco irá funcionar.
Levando tudo isso em consideração anexei um RESCUNHO do que me veio a cabeça sobre a sua questão.

Falando sobre o rascunho.

Lí as coisas que estão escritas no link que vc apontou e achei bacana o trabalho do Sr. Daniel Fernandes (parabéns e obrigado); mas percebi que o trabalho se concentra exclusivamente no padrão (MVP), parecido com vários outros bons trabalhos que tem na net.
O único problema que vejo nestes casos é que eles normalmente simplificam tanto a coisa que as vezes acabam destruindo / omitindo detalhes importantes (acredito que seja acidental).

Detalhes que gostaria que fossem observados no rascunho por vc para uma reflexão:

  1. No model, coloquei uma classe não muito óbvia, que vários atributos não esperados quando se lê o nome dela (TbCurso). Fiz assim para mostrar que o model foi construido para atender a view (sua janelinha) e muitas vezes para facilitar vc tem estruturas de dados hibridas e as vezes não; por exemplo: para apresentar o nome do aluno basta um objeto da classe aluno, mas para apresentar uma grid mais elaborada vc tem que montar uma classe com atributos que vem de tudo quanto é lado para construir os objetos que compõe a grid.

  2. No presenter, observe que para obter os dados que irão atender a view ele terá acessar um fonte de informações com base em critérios de consulta; exemplo: Apenas os alunos do mês de junho de 2006. É aqui que a coisa também fica um pouco diferente, porque vc precisa de objetos especiais para fazer isso para o presenter; conforme o rascunho vc tem os objetos de serviços que acessam os objetos repositório (neste ponto depende um pouco de como vc irá acessar a sua estrutura de dados) que e por sua vêz acessam os objetos que representam as suas entidades.

Tenho a espectativa de ter adicionado um novo e melhor caminho para este seu trabalho fazendo que outras pessoas participem deste seu post sem ter complicado as coisas.

P.S O rascunho (imagem anexa), é meramente ilustrativo, obviamente faltam vários detalhes.

flws


oi fantomas.
Realmente uma boa experiência em TI muda totalmente a visão e estrutura de um projeto. Preocupações com o funcionamento ideal do sistema tem que ter msm, não basta só fazer e pronto! Experiência que vai se adqurindo quando ta no mercado de trabalho sem dúvida! Foi ótimo o esboço que vc colocou, concerteza me ajudou bastante! principalmente a explicação. Eu agradeço muito por te-lo elaborado para me ajudar! Vou aperfeiçoar o meu projeto e coloco aqui novamente.
obrigada

Se precisar ainda de mais conteúdo sobre MVC pode acessra este tópico aqui: http://www.guj.com.br/posts/list/129277.java
Estarei adicionando o seu tópico para referencia de outros usuários no link acima! Espero ter ajudado! :wink:

Veja o post http://www.guj.com.br/posts/list/147441.java, que aponta para uma série de artigos falando de MVC/MVP.